¿Dónde está la lista de excepción de python estándar para que se muestren los programas?

Question

Hay una lista standard python exceptions que debemos tener cuidado, pero no creo que estos sean los que debemos plantearnos nosotros mismos, porque rara vez son aplicables.

Estoy ansioso por ver si existe una lista dentro de la biblioteca estándar de Python, con excepciones similares a .NET de ApplicationException, ArgumentNullException, ArgumentOutOfRangeException, InvalidOperationException - excepciones que podemos plantear nosotros mismos?

¿O hay otra manera más pitónica de manejar casos de error comunes que elevar las excepciones estándar?

EDITAR: No estoy preguntando sobre cómo manejar excepciones, pero qué tipos puedo y debo plantear donde sea necesario.

Answer 1

Si el error coincide con la descripción de una de las clases de excepciones de python estándar, entonces tírelo.

Los más comunes para usar son TypeError y ValueError, la lista a la que se ha vinculado ya es la lista estándar.

Si desea tener aplicaciones específicas, la subclase Excepción o uno de sus descendientes es el camino a seguir.

Para hacer referencia a los ejemplos que diste de .NET ApplicationException es la más cercana a RuntimeError ArgumentNullException probablemente habrá un AttributeError (tratar de llamar al método que desea, deje pitón elevar la excepción de una tipificación de pato la) AttributeOutOfRange es sólo una más específico ValueError InvalidOperationException podría ser cualquier número de excepciones aproximadamente equivalentes de la lib de python estándar.

Básicamente, elija una que refleje cualquier error que esté levantando según las descripciones de la página http://docs.python.org/library/exceptions.html.

Answer 2

La manera Pythonic es dejar pasar las excepciones desde Python. Por ejemplo, en lugar de:

def foo(arg): 
    if arg is None: 
    raise SomeNoneException 
    bar = arg.param 

Sólo haz:

def foo(arg): 
    bar = arg.param 

Si arg es None o no tiene el atributo param, obtendrá una excepción de la propia Python.

En el pitón glossary esto se llama "EAFP":

más fácil pedir perdón que permiso. Este estilo común de codificación Python asume la existencia de claves o atributos válidos y captura excepciones si la suposición prueba es falsa. Este estilo limpio y rápido es caracterizado por la presencia de muchas declaraciones try y except. La técnica contrasta con la LBYL (mirar antes de saltar) estilo común a muchos otros idiomas tales como C.

y funciona bien en conjunto con la filosofía inherente a la tipificación de pato de Python.

---

Esto no quiere decir que usted no debe crear excepciones de su cuenta, por supuesto, sólo que no es necesario para envolver las excepciones Python ya existentes.

Para sus propias excepciones, cree clases derivadas de Exception y tírelas cuando sea adecuado.

Answer 3

Primero, Python plantea excepciones estándar para usted.

Es mejor pedir perdón que pedir permiso

simplemente a intentar la operación y dejar que Python elevar la excepción. No corchetees todo con if would_not_work(): raise Exception. Nunca vale la pena escribir Python ya lo hace en todos los casos.

Si cree que debe plantear una excepción estándar, probablemente esté escribiendo demasiado código.

Es posible que deba aumentar ValueError.

def someFunction(arg1): 
    if arg1 <= 0.0: 
     raise ValueError("Guess Again.") 

De vez en cuando, puede que tenga que levantar una TypeError, pero es raro.

def someFunctionWithConstraints(arg1): 
    if isinstance(arg1,float): 
     raise TypeError("Can't work with float and can't convert to int, either") 
    etc. 

En segundo lugar, casi siempre desea crear sus propias excepciones únicas.

class MyException(Exception): 
    pass 

Eso es todo lo que se necesita para crear algo distintivo y único para su aplicación.

Answer 4

Me parece recordar haber sido entrenado por la documentación de que está bien plantear excepciones predefinidas, siempre que sean apropiadas. Por ejemplo, la forma recomendada de finalizar ya no es llamar a exit() sino más bien elevar SystemExit.

Otro ejemplo dado es reutilizar la excepción IndexError en tipos de contenedores personalizados.

Por supuesto, su aplicación debe definir sus propias excepciones en lugar de reutilizar las excepciones del sistema. Solo digo que no hay prohibición de reutilizarlos cuando corresponda.