¿Es una buena práctica usar try-except-else en Python?

¿Cuál es la razón para que exista el intento-excepto-otra cosa?

Un bloque try le permite manejar un error esperado. El bloque except solo debería capturar excepciones que esté preparado para manejar. Si maneja un error inesperado, su código puede hacer lo incorrecto y ocultar errores.

Una cláusula else se ejecutará si no hubo errores, y al no ejecutar ese código en el bloque try, evitará detectar un error inesperado. Una vez más, la captura de un error inesperado puede ocultar bichos.

Ejemplo

Por ejemplo:

try:
    try_this(whatever)
except SomeException as the_exception:
    handle(the_exception)
else:
    return something

La suite "try, except" tiene dos cláusulas opcionales, else y finally. Así que en realidad es try-except-else-finally.

else evaluará solo si no hay excepción del bloque try. Nos permite simplificar el código más complicado a continuación:

no_error = None
try:
    try_this(whatever)
    no_error = True
except SomeException as the_exception:
    handle(the_exception)
if no_error:
    return something

Así que si comparamos un else con la alternativa (que podría crear errores) vemos que reduce las líneas de código y podemos tener una más legible, mantenible, y menos código base con errores.

finally

finally se ejecutará sin importar qué, incluso si otra línea está siendo evaluada con una sentencia return.

Desglosado con pseudo-código

Podría ayudar a desglosar esto, en la forma más pequeña posible que muestre todas las características, con comentarios. Supongamos que este pseudocódigo sintácticamente correcto (pero no ejecutable a menos que se definan los nombres) está en una función.

Por ejemplo:

try:
    try_this(whatever)
except SomeException as the_exception:
    handle_SomeException(the_exception)
    # Handle a instance of SomeException or a subclass of it.
except Exception as the_exception:
    generic_handle(the_exception)
    # Handle any other exception that inherits from Exception
    # - doesn't include GeneratorExit, KeyboardInterrupt, SystemExit
    # Avoid bare `except:`
else: # there was no exception whatsoever
    return something()
    # if no exception, the "something()" gets evaluated,
    # but the return will not be executed due to the return in the
    # finally block below.
finally:
    # this block will execute no matter what, even if no exception,
    # after "something" is eval'd but before that value is returned
    # but even if there is an exception.
    # a return here will hijack the return functionality. e.g.:
    return True # hijacks the return in the else clause above

Es verdad que podríamos incluir el código en el bloque else en el bloque try en su lugar, donde se ejecutaría si no hubiera excepciones, pero ¿qué pasaría si ese código en sí mismo genera una excepción del tipo que estamos capturando? Dejarlo en el bloque try ocultaría ese error.

Queremos minimizar las líneas de código en el bloque try para evitar la captura de excepciones que no esperábamos, bajo el principio de que si nuestro código falla, queremos que falle en voz alta. Este es un mejor practice .

Entiendo que las excepciones no son errores{[30]]}

En Python, la mayoría de las excepciones son errores.

Podemos ver la jerarquía de excepciones usando pydoc. Por ejemplo, en Python 2:

$ python -m pydoc exceptions

O Python 3:

$ python -m pydoc builtins

Nos dará la jerarquía. Podemos ver que la mayoría de los tipos de Exception son errores, aunque Python usa algunos de ellos para cosas como terminar bucles for (StopIteration). Esto es Python 3 jerarquía:

BaseException
    Exception
        ArithmeticError
            FloatingPointError
            OverflowError
            ZeroDivisionError
        AssertionError
        AttributeError
        BufferError
        EOFError
        ImportError
            ModuleNotFoundError
        LookupError
            IndexError
            KeyError
        MemoryError
        NameError
            UnboundLocalError
        OSError
            BlockingIOError
            ChildProcessError
            ConnectionError
                BrokenPipeError
                ConnectionAbortedError
                ConnectionRefusedError
                ConnectionResetError
            FileExistsError
            FileNotFoundError
            InterruptedError
            IsADirectoryError
            NotADirectoryError
            PermissionError
            ProcessLookupError
            TimeoutError
        ReferenceError
        RuntimeError
            NotImplementedError
            RecursionError
        StopAsyncIteration
        StopIteration
        SyntaxError
            IndentationError
                TabError
        SystemError
        TypeError
        ValueError
            UnicodeError
                UnicodeDecodeError
                UnicodeEncodeError
                UnicodeTranslateError
        Warning
            BytesWarning
            DeprecationWarning
            FutureWarning
            ImportWarning
            PendingDeprecationWarning
            ResourceWarning
            RuntimeWarning
            SyntaxWarning
            UnicodeWarning
            UserWarning
    GeneratorExit
    KeyboardInterrupt
    SystemExit

Un comentarista preguntó:

Supongamos que tiene un método que hace ping a una API externa y desea manejar la excepción en una clase fuera del envoltorio de la API, ¿simplemente devuelve e desde el método bajo la cláusula except donde e es el objeto exception?

No, no se devuelve la excepción, solo se vuelve a subir con un desnudo raise para preservar la traza apilada.

try:
    try_this(whatever)
except SomeException as the_exception:
    handle(the_exception)
    raise

O, en Python 3, puede generar una nueva excepción y preservar backtrace with exception chaining:

try:
    try_this(whatever)
except SomeException as the_exception:
    handle(the_exception)
    raise DifferentException from the_exception

Explico enmi respuesta aquí .

Python no suscribe la idea de que las excepciones solo deben usarse para casos excepcionales, de hecho el modismo es 'pide perdón, no permiso'. Esto significa que el uso de excepciones como parte rutinaria de su control de flujo es perfectamente aceptable y, de hecho, se recomienda.

Esto es generalmente algo bueno, ya que trabajar de esta manera ayuda a evitar algunos problemas (como un ejemplo obvio, las condiciones de carrera a menudo se evitan), y tiende a hacer que el código sea un poco más legible.

Imagine que tiene una situación en la que toma una entrada de usuario que necesita ser procesada, pero tiene un valor predeterminado que ya está procesada. La estructura try: ... except: ... else: ... hace que el código sea muy legible:

try:
   raw_value = int(input())
except ValueError:
   value = some_processed_value
else: # no error occured
   value = process_value(raw_value)

Compare con cómo podría funcionar en otros idiomas:

raw_value = input()
if valid_number(raw_value):
    value = process_value(int(raw_value))
else:
    value = some_processed_value

Tenga en cuenta las ventajas. No hay necesidad de comprobar que el valor es válido y analizarlo por separado, se hacen una vez. El código también sigue una progresión más lógica, la ruta del código principal es la primera, seguida de 'si no funciona, haz esto.

El ejemplo es naturalmente un poco artificial, pero muestra que hay casos para esta estructura.

¿Es una buena práctica usar try-except-else en python?

La respuesta a esto es que depende del contexto. Si haces esto:

d = dict()
try:
    item = d['item']
except KeyError:
    item = 'default'

Demuestra que no conoces muy bien Python. Esta funcionalidad está encapsulada en el método dict.get:

item = d.get('item', 'default')

El try/except block es una forma mucho más visual y detallada de escribir lo que se puede ejecutar eficientemente en una sola línea con un método atómico. Hay otros casos en los que esto es verdad.

Sin embargo, eso no significa que debamos evitar todo manejo de excepciones. En algunos casos se prefiere evitar las condiciones de carrera. No compruebe si existe un archivo, simplemente intente abrirlo y capture el IOError apropiado. En aras de la simplicidad y la legibilidad, trate de encapsular esto o factorizarlo como apropiado.

Lee el Zen de Python, entendiendo que hay principios que están en tensión, y ten cuidado con el dogma que se basa demasiado en cualquiera de las declaraciones.

Debes tener cuidado al usar el bloque finally, ya que no es lo mismo que usar un bloque else en el intento, excepto. El bloque final se ejecutará independientemente del resultado de la excepción de prueba.

In [10]: dict_ = {"a": 1}

In [11]: try:
   ....:     dict_["b"]
   ....: except KeyError:
   ....:     pass
   ....: finally:
   ....:     print "something"
   ....:     
something

Como todo el mundo ha señalado, el uso del bloque else hace que su código sea más legible, y solo se ejecuta cuando no se lanza una excepción

In [14]: try:
             dict_["b"]
         except KeyError:
             pass
         else:
             print "something"
   ....:

Cada vez que vea esto:

try:
    y = 1 / x
except ZeroDivisionError:
    pass
else:
    return y

O incluso esto:

try:
    return 1 / x
except ZeroDivisionError:
    return None

Considere esto en su lugar:

import contextlib
with contextlib.suppress(ZeroDivisionError):
    return 1 / x

Este es mi fragmento simple sobre cómo entender try-except-else-finally block en Python:

def div(a, b):
    try:
        a/b
    except ZeroDivisionError:
        print("Zero Division Error detected")
    else:
        print("No Zero Division Error")
    finally:
        print("Finally the division of %d/%d is done" % (a, b))

Probemos div 1/1:

div(1, 1)
No Zero Division Error
Finally the division of 1/1 is done

Probemos div 1/0

div(1, 0)
Zero Division Error detected
Finally the division of 1/0 is done

Vea el siguiente ejemplo que ilustra todo sobre try-except-else-finally:

for i in range(3):
    try:
        y = 1 / i
    except ZeroDivisionError:
        print(f"\ti = {i}")
        print("\tError report: ZeroDivisionError")
    else:
        print(f"\ti = {i}")
        print(f"\tNo error report and y equals {y}")
    finally:
        print("Try block is run.")

Implementarlo y venir por:

    i = 0
    Error report: ZeroDivisionError
Try block is run.
    i = 1
    No error report and y equals 1.0
Try block is run.
    i = 2
    No error report and y equals 0.5
Try block is run.

OP, TIENES RAZÓN. El else después de try/except en Python es feo. conduce a otro objeto de control de flujo donde no se necesita ninguno:

try:
    x = blah()
except:
    print "failed at blah()"
else:
    print "just succeeded with blah"

Un equivalente totalmente claro es:

try:
    x = blah()
    print "just succeeded with blah"
except:
    print "failed at blah()"

Esto es mucho más claro que una cláusula else. El otro después de try / except no se escribe con frecuencia, por lo que toma un momento calcular cuáles son las implicaciones.

Solo porque puedas hacer algo, no significa que debas hacer algo.

Muchas características han sido añadido a los idiomas porque alguien pensó que podría ser útil. El problema es que, cuantas más características, menos claras y obvias son las cosas porque la gente no suele usar esas campanas y silbatos.

Solo mis 5 centavos aquí. Tengo que venir detrás y limpiar una gran cantidad de código escrito por desarrolladores de 1er año fuera de la universidad que piensan que son inteligentes y quieren escribir código de alguna manera uber-apretado, uber-eficiente cuando eso solo hace que sea un desastre para tratar de leer / modificar más tarde. Yo voto por legibilidad todos los días y dos veces los domingos.