Ответ 1
Как вручную выставить/создать исключение в Python?
Будь конкретным в своем сообщении, например:
raise ValueError('A very specific bad thing happened.')
Не вызывать общие исключения
Избегайте создания общего исключения. Чтобы поймать его, вам придется поймать все другие более конкретные исключения, которые подклассифицируют его.
Проблема 1: Скрытие ошибок
raise Exception('I know Python!') # Don't! If you catch, likely to hide bugs.
Например:
def demo_bad_catch():
try:
raise ValueError('Represents a hidden bug, do not catch this')
raise Exception('This is the exception you expect to handle')
except Exception as error:
print('Caught this error: ' + repr(error))
>>> demo_bad_catch()
Caught this error: ValueError('Represents a hidden bug, do not catch this',)
Проблема 2: не будет ловить
и более специфические уловы не пойдут на общее исключение:
def demo_no_catch():
try:
raise Exception('general exceptions not caught by specific handling')
except ValueError as e:
print('we will not catch exception: Exception')
>>> demo_no_catch()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in demo_no_catch
Exception: general exceptions not caught by specific handling
Рекомендации: raise statement
raise ValueError('A very specific bad thing happened')
который также позволяет легко передать произвольное количество аргументов конструктору:
raise ValueError('A very specific bad thing happened', 'foo', 'bar', 'baz')
К этим аргументам относится атрибут args объекта Exception. Например:
try:
some_code_that_may_raise_our_value_error()
except ValueError as err:
print(err.args)
печатает
('message', 'foo', 'bar', 'baz')
В Python 2.5 в BaseException был добавлен фактический атрибут message в пользу поощрения пользователей к подклассам Exceptions и прекращения использования args, но введение из message, и первоначальная устаревшая аргументация была отложена.
Рекомендации: except
Внутри предложения except вы можете, например, записать, что произошел определенный тип ошибки, а затем повторно рейз. Лучший способ сделать это при сохранении трассировки стека - использовать голый оператор raise. Например:
logger = logging.getLogger(__name__)
try:
do_something_in_app_that_breaks_easily()
except AppError as error:
logger.error(error)
raise # just this!
# raise AppError # Don't do this, you'll lose the stack trace!
Не изменяйте свои ошибки... но если вы настаиваете.
Вы можете сохранить stacktrace (и значение ошибки) с помощью sys.exc_info(), но это больше подвержено ошибкам и имеет проблемы совместимости между Python 2 и 3, предпочитайте использовать голый raise для повторного рейза.
Объяснить - sys.exc_info() возвращает тип, значение и трассировку.
type, value, traceback = sys.exc_info()
Это синтаксис в Python 2 - обратите внимание, что это несовместимо с Python 3:
raise AppError, error, sys.exc_info()[2] # avoid this.
# Equivalently, as error *is* the second object:
raise sys.exc_info()[0], sys.exc_info()[1], sys.exc_info()[2]
Если вы хотите, вы можете изменить то, что происходит с вашим новым рейзом - например, установка новых аргументов для экземпляра:
def error():
raise ValueError('oops!')
def catch_error_modify_message():
try:
error()
except ValueError:
error_type, error_instance, traceback = sys.exc_info()
error_instance.args = (error_instance.args[0] + ' <modification>',)
raise error_type, error_instance, traceback
И мы сохранили весь трассировку при изменении аргументов. Обратите внимание, что это не самая лучшая практика и это недействительный синтаксис в Python 3 (что затрудняет работу с совместимостью).
>>> catch_error_modify_message()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in catch_error_modify_message
File "<stdin>", line 2, in error
ValueError: oops! <modification>
В Python 3:
raise error.with_traceback(sys.exc_info()[2])
Опять же: избегайте ручного управления трассировками. Он менее эффективен и больше подвержен ошибкам. И если вы используете потоки и sys.exc_info, вы можете даже получить неправильную трассировку (особенно, если вы используете обработку исключений для потока управления, что я лично стараюсь избегать).
Python 3, цепочка исключений
В Python 3 вы можете связать Исключения, которые сохраняют tracebacks:
raise RuntimeError('specific message') from error
Знайте:
- это позволяет изменить тип ошибки, и
- это несовместимо с Python 2.
Устаревшие методы:
Они могут легко скрыть и даже попасть в производственный код. Вы хотите создать исключение, и для них вы получите исключение, , но не тот, который был предназначен!
Действителен в Python 2, но не в Python 3:
raise ValueError, 'message' # Don't do this, it deprecated!
Только действует во многих более старых версиях Python (2.4 и ниже), вы все равно можете видеть людей, которые поднимают строки:
raise 'message' # really really wrong. don't do this.
Во всех современных версиях это фактически вызовет TypeError, потому что вы не поднимаете тип BaseException. Если вы не проверяете правильное исключение и не имеете рецензента, который знает о проблеме, он может войти в производство.
Пример использования
Я создаю исключения, чтобы предупреждать пользователей моего API, если они используют его неправильно:
def api_func(foo):
'''foo should be either 'baz' or 'bar'. returns something very useful.'''
if foo not in _ALLOWED_ARGS:
raise ValueError('{foo} wrong, use "baz" or "bar"'.format(foo=repr(foo)))
Создайте свои собственные типы ошибок, когда apropos
"Я хочу сделать ошибку специально, чтобы она включалась в"
Вы можете создавать свои собственные типы ошибок, если вы хотите указать что-то конкретное в своем приложении, просто подклассифицируйте соответствующую точку в иерархии исключений:
class MyAppLookupError(LookupError):
'''raise this when there a lookup error for my app'''
и использование:
if important_key not in resource_dict and not ok_to_be_missing:
raise MyAppLookupError('resource is missing, and that is not ok.')