Generar (lanzar) manualmente una excepción en Python

¿Cómo lanzo/provoco manualmente una excepción en Python?

Utilice el constructor de excepciones más específico que se ajuste semánticamente a su problema .

Sea específico en su mensaje, por ejemplo:

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

No plantee excepciones genéricas

Evite plantear un genérico Exception. Para detectarlo, tendrá que detectar todas las demás excepciones más específicas que lo subclasifican.

Problema 1: ocultar errores

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

Por ejemplo:

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: no capta

Y capturas más específicas no detectarán la excepción general:

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

Mejores prácticas: raisedeclaración

En su lugar, utilice el constructor de excepciones más específico que se ajuste semánticamente a su problema .

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

que también permite pasar cómodamente un número arbitrario de argumentos al constructor:

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

A estos argumentos se accede mediante el argsatributo del Exceptionobjeto. Por ejemplo:

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

huellas dactilares

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

En Python 2.5, messagese agregó un atributo real BaseExceptiona favor de alentar a los usuarios a crear subclases de excepciones y dejar de usar args, pero se retiró la introducciónmessage y la desaprobación original de args .

Mejores Prácticas: exceptcláusula

Cuando esté dentro de una cláusula de excepción, es posible que desee, por ejemplo, registrar que ocurrió un tipo específico de error y luego volver a generarlo. La mejor manera de hacer esto preservando el seguimiento de la pila es utilizar una declaración de aumento simple. Por ejemplo:

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!

No modifiques tus errores... pero si insistes.

Puede conservar el seguimiento de la pila (y el valor de error) con sys.exc_info(), pero esto es mucho más propenso a errores y tiene problemas de compatibilidad entre Python 2 y 3 ; prefiera usar un bare raisepara volver a generar.

Para explicar: sys.exc_info()devuelve el tipo, el valor y el rastreo.

type, value, traceback = sys.exc_info()

Esta es la sintaxis en Python 2; tenga en cuenta que no es compatible con 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]

Si lo deseas, puedes modificar lo que sucede con tu nuevo aumento, por ejemplo, estableciendo un nuevo argspara la instancia:

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

Y hemos conservado todo el rastreo mientras modificamos los argumentos. Tenga en cuenta que esta no es una práctica recomendada y su sintaxis no es válida en Python 3 (lo que hace que sea mucho más difícil mantener la compatibilidad).

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

En Python 3 :

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

Nuevamente: evite manipular manualmente los rastreos. Es menos eficiente y más propenso a errores. Y si está utilizando subprocesos e sys.exc_infoincluso puede obtener un rastreo incorrecto (especialmente si está utilizando el manejo de excepciones para el flujo de control, lo cual personalmente tendería a evitar).

Python 3, encadenamiento de excepciones

En Python 3, puedes encadenar excepciones, que preservan los rastreos:

raise RuntimeError('specific message') from error

Tenga en cuenta:

• esto permite cambiar el tipo de error generado, y
• esto no es compatible con Python 2.

Métodos obsoletos:

Estos pueden ocultarse fácilmente e incluso ingresar al código de producción. Quiere generar una excepción y, al hacerlo, se generará una excepción, ¡ pero no la prevista!

Válido en Python 2, pero no en Python 3 es lo siguiente:

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

Solo es válido en versiones mucho más antiguas de Python (2.4 y anteriores), es posible que aún veas personas levantando cadenas:

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

En todas las versiones modernas, esto en realidad generará un TypeError, porque no estás generando un BaseExceptiontipo. Si no está verificando la excepción correcta y no tiene un revisor que esté al tanto del problema, podría entrar en producción.

Uso de ejemplo

Planteo Excepciones para advertir a los consumidores sobre mi API si la están usando 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)))

Cree sus propios tipos de error cuando sea necesario

"Quiero cometer un error a propósito, para que entre en excepción"

Puede crear sus propios tipos de error, si desea indicar que algo específico está mal con su aplicación, simplemente subclase el punto apropiado en la jerarquía de excepciones:

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

y uso:

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

Jun 05 '2014 16:06 Russia Must Remove Putin