Comment ne pas gérer les exceptions en Python

• La pire façon de le faire
• Une meilleure façon d'attraper toutes les exceptions
• C'est encore pire
• Attrapez ce que vous pouvez gérer
• Conclusion

La pire façon de le faire

Le pire que vous puissiez faire est de créer un bloc try-except qui intercepte tout. Par fourre-tout, j'entends quelque chose comme :

try:
    ...
except:
    pass

Les blocs fourre-tout comme ceux-ci sont mauvais car :

1. Vous n'avez aucune idée des autres exceptions qui pourraient être levées (nous en reparlerons plus tard).
2. Nous masquons l'exception en utilisant silencieusement pass au lieu de consigner l'erreur.

De plus, un sauf vide attrapera tout, y compris KeyboardInterrupt (contrôle + c), SystemExit , et même NameErrors ! Cela signifie que le code suivant ne peut pas être arrêté proprement :

from time import sleep

while True:
    try:
        print("Try and stop me")
        sleep(1)
    except:
        print("Don't.. stop.. me now!")

N'hésitez pas à l'essayer. Vous devez fermer la fenêtre de votre terminal ou tuer le processus Python pour arrêter ce programme.

Une meilleure façon d'attraper toutes les exceptions

En revanche, lors de l'utilisation de except Exception , bien qu'il s'agisse toujours d'un moyen rapide et sale d'attraper trop d'exceptions, vous pourrez au moins arrêter correctement le processus en cours d'exécution :

from time import sleep
while True:
    try:
        print("Try and stop me")
        sleep(1)
    except Exception:
        print("Ok I'll stop!")

En attrapant Exception vous n'attraperez pas SystemExit , KeyboardInterrupt et autres exceptions similaires. Pourquoi est-ce, demandez-vous ?

Toutes les exceptions héritent d'une classe appelée BaseException . D'après la documentation officielle :"In a try déclaration avec un except clause qui mentionne une classe particulière, cette clause gère également toutes les classes d'exception dérivées de cette classe. Un except vide est équivalent à except BaseException , par conséquent, il détectera toutes les exceptions possibles.

En revanche, la classe Exception est défini comme suit :« Toutes les exceptions intégrées, ne sortant pas du système, sont dérivées de cette classe. Toutes les exceptions définies par l'utilisateur doivent également être dérivées de cette classe."

C'est encore pire

Dans l'exemple suivant, nous utilisons la bibliothèque os pour obtenir le répertoire de travail actuel. Cependant, mes petits doigts gras ont fait une faute de frappe :

import os
try:
    working_dir = os.getcdw()
    print(working_dir)
except:
    print('error')

Parce que os.getcdw n'est pas une fonction dans le module os, une NameError est renvoyée. Au lieu d'échouer, la clause except captera l'erreur, affichera "error" et le programme continuera malgré notre faute de frappe flagrante. Malheureusement, celui-ci n'est pas résoluble en attrapant Exception non plus !

Apparemment, notre petite astuce de la première étape n'est pas une solution à tous nos problèmes. Alors que devrait nous faisons ?

Attrapez ce que vous pouvez gérer

Une phrase souvent entendue à propos des exceptions est :attrapez ce que vous pouvez gérer . De nombreux développeurs sont tentés de traiter directement les exceptions, alors qu'il est souvent préférable de laisser l'exception se propager à une partie de votre programme qui peut réellement la gérer.

Par exemple, considérons la partie d'un éditeur de texte qui ouvre et charge des fichiers, appelons-la OpenFile classer. Si l'utilisateur a demandé à ouvrir un fichier qui n'existe pas, vous pouvez soit gérer directement cette erreur, soit la laisser se propager.

Dans ce cas, il vaut mieux propager l'exception à l'appelant, car OpenFile n'a aucune idée de la gravité de cette exception pour l'appelant. L'appelant peut gérer la situation de plusieurs manières :

• Il pourrait créer un nouveau fichier avec ce nom à la place et continuer
• Peut-être que l'appelant a besoin que le fichier soit là, auquel cas il peut afficher une boîte de dialogue d'erreur pour informer l'utilisateur que ce fichier n'existe pas.

Quoi qu'il en soit, ce n'est pas le OpenFile classe pour décider quoi faire en cas de FileNotFoundError .

Une exception doit-elle toujours être propagée ? Non. Une exception possible qui peut être gérée dans la classe FileOpen est le TimeoutError . Vous voudrez peut-être réessayer plusieurs fois, par exemple, sans déranger l'appelant avec l'erreur. Ceci est une exception que OpenFile peut gérer, vous pouvez donc l'attraper et réessayer.

Conclusion

Vous ne devez en aucun cas intercepter plus d'exceptions que vous ne pouvez en gérer. La couverture à l'exception des blocs est une recette pour les bogues et le code imprévisible. En d'autres termes :attrapez ce que vous pouvez gérer.

Si vous écrivez votre code en gardant à l'esprit la matra "attrapez ce que vous pouvez gérer", écrire des blocs fourre-tout enfreint toutes les règles. Alors s'il vous plaît, arrêtez de le faire. En guise d'exercice, vous pouvez revoir une partie de votre code existant et voir s'il peut être amélioré avec ces nouvelles connaissances !