Criar manualmente (lançar) uma excepção em Python

Como faço para abrir/abrir uma excepção manualmente em Python?

Use o construtor de excepções mais específico que se encaixa semanticamente no seu problema .

Seja específico na sua mensagem, por exemplo:

raise ValueError('A very specific bad thing happened.')

Não levantem excepções genéricas

Evite criar uma excepção genérica. Para apanhá-lo, terá de apanhar todas as outras excepções mais específicas que subclassificam.

Problema 1: esconder insectos

raise Exception('I know Python!') # Don't! If you catch, likely to hide bugs.

Para exemplo:

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',)

Problema 2: não vai pegar

E as capturas mais específicas não apanharão a excepção geral:

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

Boas Práticas: raise declaração

Em vez disso, use o construtor de exceções mais específico que se encaixa semanticamente no seu problema .

raise ValueError('A very specific bad thing happened')

O que também habilmente permite que um número arbitrário de argumentos seja passado para o construtor:

raise ValueError('A very specific bad thing happened', 'foo', 'bar', 'baz') 

Estes argumentos são acedidos pelo atributo args na excepção objecto. Por exemplo:

try:
    some_code_that_may_raise_our_value_error()
except ValueError as err:
    print(err.args)

Impressões digitais

('message', 'foo', 'bar', 'baz')    

No Python 2.5, um atributo real message foi adicionado ao BaseException em favor de encorajar os utilizadores a subclassar exceções e parar de usar args, mas a introdução de message e a depreciação original do args foi retraída.

Melhores práticas: except cláusula

Quando dentro de uma cláusula de excepção, você pode querer, por exemplo, registar que um tipo específico de erro aconteceu, e, em seguida, re-raise. O a melhor maneira de fazer isso enquanto preserva o traço da pilha é usar uma instrução de raise nua. Por exemplo:

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!

Não modifique os seus erros... mas se insistes.

Você pode preservar o stacktrace (e valor de erro) com sys.exc_info(), mas este é o caminho mais propensas a erro e tem problemas de compatibilidade entre o Python 2 e 3, prefira usar um nua raise para re-raise.

Para explicar-o sys.exc_info() devolve o tipo, o valor e o traceback.

type, value, traceback = sys.exc_info()

Esta é a sintaxe em Python 2-note que não é compatível com 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]

Se você quiser, você pode modificar o que acontece com o seu novo aumento-por exemplo, definir novos args para o exemplo:

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

E preservamos todo o traceback enquanto modificamos os args. Note que esta não é uma boa prática e é uma sintaxe inválida no Python 3 (tornando a compatibilidade muito mais difícil de trabalhar).

>>> 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>

Em Python 3:

    raise error.with_traceback(sys.exc_info()[2])

Mais uma vez, evite manipular manualmente as tracebacks. É menos eficiente e mais propenso a erros. E se você está usando threading e sys.exc_info você pode até mesmo obter o traceback errado (especialmente se você está usando o manuseio de exceção para o fluxo de controle - que eu pessoalmente tendem a evitar.)

Python 3, excepção encadeamento

No Python 3, podem ser feitas excepções em cadeia, que preservam as tracebacks:

    raise RuntimeError('specific message') from error

Be ciente:

• isto permite alterar o tipo de erro levantado, e
• isto é não compatível com o Python 2.

Métodos Depreciados:

Estes podem esconder-se facilmente e até entrar em código de produção. Você quer levantar uma exceção, e fazê-los vai levantar uma exceção, mas não o pretendido!

Válido no Python 2, mas não no Python 3 é o seguinte:

raise ValueError, 'message' # Don't do this, it's deprecated!

Apenas válido em versões muito mais antigas do Python (2.4 e inferior), poderá ainda ver pessoas a criar cadeias de caracteres:

raise 'message' # really really wrong. don't do this.

Em todas as versões modernas, isto irá criar um erro tipográfico, porque não está a criar um tipo de imagem de base. Se você não está verificando para a exceção certa e não tem um crítico que está ciente do problema, ele pode entrar em produção.

Uso De Exemplo

Abro excepções para avisar os consumidores da minha API se a estiverem a usar. incorrectamente:

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)))

Crie os seus próprios tipos de erros quando apropos

"eu quero cometer um erro de propósito, para que ele iria para o exceto"

Você pode criar os seus próprios tipos de erros, se quiser indicar que algo específico está errado com a sua aplicação, basta subclassar o ponto apropriado na hierarquia de excepções:

class MyAppLookupError(LookupError):
    '''raise this when there's a lookup error for my app'''

E utilização:

if important_key not in resource_dict and not ok_to_be_missing:
    raise MyAppLookupError('resource is missing, and that is not ok.')