Est-ce une bonne pratique d'utiliser try-except-else en Python?

Quelle est la raison de l'essai-sauf-pour exister?

un bloc try vous permet de gérer une erreur attendue. Le bloc except ne doit saisir que les exceptions que vous êtes prêt à gérer. Si vous gérez une erreur inattendue, votre code peut faire la mauvaise chose et cacher des bogues.

une clause else s'exécute s'il n'y a pas d'erreurs, et en n'exécutant pas ce code dans le try bloc, vous éviter d'attraper une erreur inattendue. Encore une fois, attraper une erreur inattendue peut cacher des bogues.

exemple

par exemple:

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

la suite "essayer, sauf" comporte deux clauses facultatives, else et finally . Donc c'est en fait try-except-else-finally .

else n'est évalué que s'il n'y a pas d'exception au bloc try . Il nous permet de simplifier le plus code compliqué ci-dessous:

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

donc si nous comparons un else à l'alternative (qui pourrait créer des bogues) nous voyons qu'il réduit les lignes de code et nous pouvons avoir un code-base plus lisible, maintenable, et moins bogué.

finally

finally s'exécutera quoi qu'il arrive, même si une autre ligne est évaluée avec une instruction de retour.

ventilé avec pseudo-code

il pourrait aider à décomposer cela, dans la plus petite forme possible qui montre toutes les caractéristiques, avec des commentaires. Supposons que ce pseudo-code syntaxiquement correct (mais non exécutable à moins que les noms ne soient définis) soit dans une fonction.

par exemple:

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

il est vrai que nous pourrions inclure le code dans le bloc else dans le bloc try à la place, où il serait courir s'il n'y avait pas d'exceptions, mais que faire si ce code lui-même soulève une exception du genre que nous attrapons? Le laisser dans le bloc try cacherait ce bug.

nous voulons minimiser les lignes de code dans le bloc try pour éviter d'attraper des exceptions auxquelles nous ne nous attendions pas, en vertu du principe que si notre code échoue, nous voulons qu'il échoue bruyamment. Il s'agit d'une meilleure pratique .

c'est mon comprendre que les exceptions ne sont pas des erreurs

en Python, la plupart des exceptions sont des erreurs.

nous pouvons voir la hiérarchie des exceptions en utilisant pydoc. Par exemple, en Python 2:

$ python -m pydoc exceptions

ou Python 3:

$ python -m pydoc builtins

nous donnera la hiérarchie. Nous pouvons voir que la plupart des types de Exception sont des erreurs, bien que Python utilise certains d'entre eux pour des choses comme la fin des boucles for ( StopIteration ). C'est la hiérarchie de Python 3:

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 commentateur a demandé:

dites que vous avez une méthode qui envoie une API externe et que vous voulez gérer l'exception dans une classe en dehors de L'enveloppe de L'API, est-ce que vous renvoyez simplement e de la méthode sous la clause except où e est l'objet d'exception?

Non, vous n'avez pas de retour de l'exception, juste à sur-relancer avec un nu raise pour préserver le stacktrace.

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

ou, en Python 3, vous pouvez soulever une nouvelle exception et préserver le backtrace avec le chaînage d'exception:

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

je développe dans ma réponse ici .

Python ne souscrit pas à l'idée que les exceptions ne devraient être utilisées que dans des cas exceptionnels, en fait l'idiome est "demander pardon, pas la permission" . Cela signifie que l'utilisation d'exceptions comme partie de routine de votre contrôle de flux est parfaitement acceptable, et en fait, encouragé.

c'est généralement une bonne chose, car travailler de cette façon permet d'éviter certains problèmes (comme un exemple évident, les conditions de course sont souvent évitées), et il a tendance à rendre le code un peu plus lisible.

Imaginez que vous avez une situation où vous prenez une entrée utilisateur qui doit être traitée, mais que vous avez une entrée par défaut qui est déjà traitée. La structure try: ... except: ... else: ... rend le code très lisible:

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

comparez à la façon dont il pourrait fonctionner dans d'autres langues:

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

notez les avantages. Il n'est pas nécessaire de vérifier la valeur est valide et l'analyser séparément, ils sont fait une fois. Le code suit également une progression plus logique, le chemin principal du code est le premier, suivi de "si ça ne marche pas, faites ceci".

L'exemple est naturellement un peu artificiel, mais il montre qu'il existe des cas pour cette structure.

est-ce une bonne pratique d'utiliser try-except-else en python?

la réponse à cette question Est qu'elle dépend du contexte. Si vous faites cela:

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

cela démontre que vous ne connaissez pas très bien Python. Cette fonctionnalité est encapsulée dans la méthode dict.get :

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

le bloc try / except est beaucoup plus encombré visuellement et verbeuse façon d'écrire ce qui peut être exécuté efficacement dans une seule ligne avec une méthode atomique. Il y a d'autres cas où c'est vrai.

Toutefois, cela ne signifie pas que nous devrions éviter toute manipulation d'exception. Dans certains cas, il est préférable d'éviter des conditions de course. Ne Vérifiez pas si un fichier existe, essayez juste de l'ouvrir, et attrapez l'IOError approprié. Pour des raisons de simplicité et de lisibilité, essayez de l'encapsuler ou de le prendre en compte.

lire le Zen de Python , en comprenant qu'il ya des principes qui sont en tension, et méfiez-vous du dogme qui repose trop lourdement sur l'un des énoncés en elle.

Vous devez être prudent sur l'utilisation du bloc finally, ce n'est pas la même chose que d'utiliser un autre bloc dans l'essai, à l'exception de. Le bloc final sera exécuté quel que soit le résultat de l'essai sauf.

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

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

comme tout le monde l'a noté en utilisant le bloc else rend votre code plus lisible, et ne s'exécute que lorsqu'une exception n'est pas lancée

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

chaque fois que vous voyez ceci:

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

ou même ceci:

try:
    return 1 / x
except ZeroDivisionError:
    return None

au lieu de:

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

c'est mon petit détail simple sur la façon de comprendre try-sauf-else-enfin bloquer 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))

essayons div 1/1:

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

essayons div 1/0

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

voir l'exemple suivant qui illustre tout sur try-sauf-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.")

L'implémenter et venir:

    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, VOUS AVEZ RAISON. L'autre après le try/except en Python, c'est moche . elle conduit à un autre objet de régulation du débit là où aucun n'est nécessaire:

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

un équivalent totalement clair est:

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

c'est beaucoup plus clair qu'une autre clause. L'autre chose après try/except n'est pas souvent écrit, il faut un moment pour comprendre ce que seront les conséquences.

juste parce que vous pouvez fais quelque chose, ça ne veut pas dire que tu dois faire quelque chose.

beaucoup de fonctionnalités ont été ajoutées aux langues parce que quelqu'un a pensé que cela pourrait être utile. Le problème, c'est que plus il y a de traits, moins les choses sont claires et évidentes parce que les gens n'utilisent pas habituellement ces cloches et sifflets.

juste mes 5 cents. Je dois venir derrière et nettoyer beaucoup de code écrit par les développeurs de première année de l'université qui pensent qu'ils sont intelligents et veulent Ecrire le code d'une manière Uber-tight, uber-efficace quand cela le rend juste un gâchis pour essayer et lire / modifier plus tard. Je vote pour la lisibilité tous les jours et deux fois le dimanche.