Un programme qui s'arrête net devant vous est problématique. Mais un programme qui continue en silence sans jamais dire ce qu'il a raté au passage l'est davantage. Je me suis posé cette question plus d'une fois depuis que j'ai commencé à apprendre python en autodidacte, le soir, avec ce qu'il me reste d'énergie après le travail. La gestion des erreurs, ça a l'air d'un détail technique quand on débute. Ça ne l'est pas.
Avant d'aller plus loin, un mot sur ce journal : il contient quelques liens affiliés, et si vous cliquez puis achetez quelque chose, je touche une petite commission sans que ça ne change le prix pour vous. Le seul outil que je mentionne aujourd'hui avec conviction, c'est la Formation au langage Python [Mon point de départ], celle qui m'a vraiment aidée à sortir du brouillard des débuts.
Sans filet, l'erreur arrête tout
Un soir, je travaillais sur mon petit script de suivi de budget, le genre de projet qu'on garde pour s'entraîner sans trop de pression. J'avais fini par réussir à utiliser la fonction input python pour créer un programme interactif qui me demandait mes dépenses du jour, une par une. Fière de moi, j'ai tapé une réponse trop vite : « 12s » au lieu de « 12 ».
Résultat : le programme s'est arrêté net, avec un mur de texte rouge et un ValueError que je ne savais pas encore lire. Toutes les dépenses saisies dans les minutes précédentes ont disparu avec lui, sans discussion possible. C'est ça, coder sans rien pour rattraper la chute : la moindre faute de frappe suffit à tout faire tomber.
Mon voisin de palier, Gaultier, aurait sans doute réglé ça en quelques minutes. Sauf qu'il a une règle qu'il rappelle à chaque occasion : il préfère que je cherche par moi-même avant d'aller frapper chez lui. Alors j'ai ouvert la documentation officielle toute seule, un samedi matin, bien décidée à comprendre sans aide extérieure.
Sans exemple concret sous les yeux, les explications restaient abstraites, et j'ai refermé l'onglet presque aussi perdue qu'avant. Ce détour n'a rien donné, mais il m'a au moins convaincue d'une chose : lire une définition ne suffit pas quand on n'a jamais vu le problème se produire sous ses propres yeux.
Try except : le cœur de la gestion des erreurs en python
Je dis à Python quelque chose comme : essaie (try) de faire ceci, et si ça casse d'une façon précise, ne t'arrête pas, fais plutôt cela (except). Ce jour-là, en tapant mon premier bloc qui fonctionnait, j'ai eu la sensation d'avoir posé un disjoncteur sur mon tableau électrique plutôt qu'un simple bout de code. Le programme ne mourait plus à la première maladresse — il répondait juste : réessaie, ce n'est pas un nombre.
Vérifier la saisie avec un if avant de m'en servir, j'y ai pensé, mais le réflexe d'essayer d'abord et de rattraper ensuite est venu plus naturellement une fois le principe compris. Ma tasse de thé, à ce moment-là, n'était déjà plus vraiment chaude — juste tiède contre mes doigts, preuve que j'étais penchée sur cet écran depuis un moment. Ce qui m'a le plus marquée, c'est d'avoir rouvert le fichier le lendemain et compris chaque ligne sans avoir besoin de mes notes de la veille.
Attraper toutes les erreurs avec except
Un except tout court, sans rien préciser, ça marche, mais c'est un peu comme répondre à un médecin « j'ai mal » sans dire où. J'ai vite préféré viser juste : si je divise mon budget par un nombre d'économies resté à zéro, c'est une ZeroDivisionError, et si le souci vient d'un texte glissé à la place d'un chiffre, c'est un ValueError. Nommer l'erreur précisément change tout, parce que le programme peut alors réagir différemment selon ce qui a vraiment cassé.
Le langage Python est aussi pointilleux sur l'endroit exact où on place son except par rapport au try, une question d'indentation que je n'aborde pas ici. Le message d'erreur en lui-même reste tout un sujet à part — je le garde pour un autre soir, avec mes astuces pour déboguer son code python sans perdre patience le soir. Je pourrais aussi ranger tout ce mécanisme dans une fonction pour ne plus le retaper à chaque script, mais je n'en suis pas encore là.
Quand mieux vaut laisser planter
Gwilherm, un type que j'ai croisé en ligne et avec qui je continue d'échanger, m'a fait remarquer quelque chose que je n'avais pas vu venir. Il utilise python pour surveiller les données de ses équipements dans son métier de maintenance, et pour lui, attraper une erreur sans réfléchir peut cacher une panne matérielle bien plus grave qu'une faute de frappe. Ça rejoint un peu ce que je me dis parfois en regardant de loin la Formation Cisco : réseaux et systèmes [Pour plus tard] — comprendre comment un système réagit à une panne, c'est un métier à part entière.
Dans mon script de budget, si une erreur passe inaperçue, au pire mes calculs sont faux et je m'en rends compte le lendemain. Sur les équipements dont Gwilherm s'occupe, laisser le système continuer à tourner après une erreur mal comprise peut coûter bien plus cher qu'un chiffre erroné. Alors la règle que je retiens tient en une phrase : j'attrape l'erreur quand je sais quoi faire d'utile ensuite, et je laisse le programme s'arrêter quand je préfère qu'il se taise plutôt qu'il improvise.
Garder le programme debout, pas parfait
En deux ans à taper du code le soir, je n'ai toujours pas de script parfait, et ce n'est plus vraiment mon objectif. Ce que je vise, c'est un programme qui sait quoi faire quand il rencontre un problème plutôt qu'un programme qui prétend ne jamais en rencontrer. Un message d'erreur poli reste tout de même bien plus rassurant qu'un terminal qui se ferme sans un mot d'explication.
Pour qui veut transformer ses soirées en séances de code à peu près productives, je recommande sincèrement la Formation au langage Python [Mon point de départ], celle qui m'a appris à ne plus redouter le texte rouge. Il y a aussi la JavaScript : formation 100 % pratique [Autre piste] qui traîne dans un coin de ma tête pour plus tard, même si mener deux langages de front dépasse largement mes forces du moment. Reste une question que je n'ai toujours pas tranchée : à partir de quand un programme qui rattrape tout devient-il plus dangereux que celui qui n'attrape rien ?