Gestion des erreurs Python : essayez / except / else / enfin en 2026

La gestion des erreurs sépare le « code qui fonctionne sur votre machine » du « code qui survit à la production ». Le « try / except » de Python semble simple, mais la forme complète à quatre mots-clés — « try / except / else / enfin » — code une quantité surprenante de structure que la plupart des didacticiels ignorent.

Ce guide couvre : la signification réelle de chaque mot-clé, les six modèles que vous verrez dans chaque base de code backend, quand définir vos propres exceptions et les trois anti-modèles qui laissent passer les bogues après vos tests.

Les quatre mots-clés, justement

La clause « else » est sous-utilisée. Il dit "ce prochain bit dépend de la réussite de l'essai, mais je ne veux pas qu'il soit protégé par la même chose, sauf". C'est le bon endroit pour la continuation du chemin heureux — le placer dans try détecte accidentellement les exceptions non liées de ship(result).

Les six modèles

1. Réessayez en cas d'échec transitoire

Règle : réessayer UNIQUEMENT sur des erreurs passagères (réseau, timeout, 429, 503). Ne réessayez jamais sur ValueError, KeyError, TypeError - ce sont des bogues de code, et réessayer exécute simplement le bogue trois fois.

2. Garde avec else

Le « else » garantit que le « fichier » a été ouvert avec succès ET étend le nettoyage avec « with ». Remarque : process() peut déclencher ValueError — qui se propagera et NE sera PAS intercepté par sauf FileNotFoundError.

3. Nettoyage avec finally (avant que with n'existe)

Dans le code moderne, vous utiliseriez with db.connect() comme conn : — with est le sucre par rapport à try / finalement pour le cas de nettoyage courant. Recherchez « enfin » explicite uniquement lorsque la ressource ne prend pas en charge le protocole du gestionnaire de contexte.

4. Re-relancer avec un contexte supplémentaire

raise NewException(...) from e chaîne l'exception d'origine sur la nouvelle afin que le traçage affiche les DEUX. N'écrivez jamais raise NewException(str(e)) — cela supprime le traçage d'origine.

5. Attrapez l'exception la plus étroite possible

Règle : plus l'exception est étroite, mieux c'est. Si vous ne savez pas quel « processus » peut déclencher, exécutez-le et découvrez-le. sauf exception : est une odeur de code 90 % du temps.

6. raise à l'intérieur de sauf — relance proprement

Le simple «raise» conserve le traçage d'origine intact. Ne jamais «raise e» (Python 3 est intelligent à ce sujet, mais «raise» nu est la forme idiomatique).

Exceptions personnalisées : quand cela en vaut la peine

Définissez votre propre classe d'exception lorsque :

1. Les appelants doivent spécifiquement « sauf MyError : » (c'est-à-dire que vous disposez d'une API appelable et que les utilisateurs doivent créer une branche en fonction du type d'échec).

2. Votre bibliothèque/service génère plusieurs erreurs liées qui partagent le contexte.

Désormais, les appelants peuvent détecter largement (sauf PaymentError) ou étroitement (sauf CardDeclinedError). Les attributs structurés sur l'exception (e.card_last4) permettent aux gestionnaires d'erreurs de créer une UX utile sans analyser les messages d'exception.

Anti-modèle : définissant une exception personnalisée qui n'existe que pour être déclenchée une seule fois et jamais interceptée. C'est juste raise ValueError("..."). Les exceptions personnalisées gagnent leur poids en étant attrapées.

Trois anti-modèles qui cachent les bugs

Anti-motif 1 : Nu sauf

Le simple sauf capte les signaux qui doivent quitter le programme (Ctrl-C, sys.exit, MemoryError). N’écrivez jamais ça. Si vous voulez vraiment intercepter toutes les exceptions non fatales, utilisez « except Exception : » — qui en intercepte TOUJOURS trop, mais respecte au moins Ctrl-C.

Anti-modèle 2 : Mise au silence sans journalisation

Chaque exception interceptée doit être soit gérée (avec une solution de repli spécifique), soit enregistrée. pass dans un except est un bug au ralenti — le code semble fonctionner tout en supprimant silencieusement les données.

Anti-modèle 3 : sauf exception : autour de tout

Problème : si stripe.charge a réussi mais que send_receipt a échoué, le client a été facturé ET vous avez avalé l'erreur. Le « sauf » couvre quatre modes de défaillance différents, et vous ne pouvez pas les distinguer.

Correction : restreindre la portée de l'essai + créer une branche sauf par limite de module.

Chaque essai couvre UNE opération. Chacun sauf sait quoi faire face à CET échec spécifique. Il s'agit d'une gestion des erreurs de niveau production.

Une bonne gestion des erreurs relève plus de la conception que de la syntaxe. try / except / else / enfin vous donne les outils ; la discipline choisit le bon type, la portée d'essai la plus étroite possible et ne fait jamais taire les erreurs que vous ne comprenez pas.

Prochaine étape : le Foundations track comprend 10 leçons sur la gestion des exceptions, les exceptions personnalisées et l'instruction "with" – avec du vrai Python exécuté dans votre navigateur.