Dans tout programme, il y a potentiellement une gestion des erreurs à mettre en place.

Pete Goodliffe a écrit un article traitant de l’importance de la gestion de ces erreurs. En voici la traduction française.

Je me promenais un soir dans la rue pour rencontrer des amis dans un bar. Nous n’avions pas partagé une bière depuis un certain temps, et j’étais impatient de les revoir. Dans ma hâte, je ne regardais pas où j’allais. J’ai trébuché au bord d’un trottoir et fini à plat ventre. Eh bien, cela m’a bien servi de ne pas faire attention, je suppose.

Cela me faisait mal à la jambe, mais j’étais pressé de rencontrer mes amis. Donc, je me suis relevé et continué. En marchant plus loin, la douleur empirait. Bien que je l’avais d’abord rejeté comme un choc, j’ai rapidement réalisé qu’il y avait quelque chose qui n’allait pas.

Mais je me suis précipité au bar avec indifférence. J’étais à l’agonie au moment où je suis arrivé. Je n’ai pas eu une bonne soirée, parce que j’étais terriblement distrait. Le matin, je suis allé chez le médecin et j’ai découvert que j’avais fracturé mon tibia. Si je m’étais arrêté quand j’ai senti la douleur, j’aurais pu évité beaucoup de dégâts supplémentaires en marchant dessus. Probablement le pire matin ma vie.

Trop de programmeurs écrivent du code ressemblant à ma soirée désastreuse.

Erreur, quelle erreur ? Ce ne sera pas sérieux. Franchement. Je peux l’ignorer. Ce n’est pas une stratégie gagnante pour le code solide. En fait, c’est juste la paresse. (Le mauvais type.) Peu importe à quel point vous pensez qu’une erreur est dans votre code, vous devriez toujours le vérifier et toujours le gérer. À chaque fois. Vous ne gagnez pas de temps si vous ne le faites pas; vous stockez des problèmes potentiels pour l’avenir.

Nous signalons des erreurs dans notre code de plusieurs façons, y compris :

• Les codes de retour peuvent être utilisés car la valeur résultante d’une fonction signifie «cela n’a pas fonctionné». Les codes de retour d’erreur sont beaucoup trop faciles à ignorer. Vous ne verrez rien dans le code pour mettre en évidence le problème. En effet, il est devenu normal d’ignorer certaines valeurs de retour des fonctions C standard. À quelle fréquence vérifiez-vous la valeur de retour de printf ?
• errno est une curieuse C aberration, une variable globale distincte définie pour signaler une erreur. Il est facile d’ignorer, difficile à utiliser, et mène à toutes sortes de problèmes désagréables – par exemple, que se passe-t-il lorsque plusieurs threads appellent la même fonction ? Certaines plateformes vous isolent de la douleur ici; d’autres ne le font pas.
• Les exceptions sont un moyen plus structuré de signalisation et de gestion des erreurs. Et vous ne pouvez pas les ignorer. Ou pouvez-vous? J’ai vu beaucoup de code comme ça :
  

  try {
  // …do something…
  }
  catch (…) {} // ignore errors

  La grâce salvatrice de cette terrible construction est telle qu’elle met en évidence le fait que vous faites quelque chose de moralement douteux.

Si vous ignorez une erreur, fermez les yeux et prétendez que rien ne va mal, vous courez de grands risques. Tout comme ma jambe s’est retrouvée dans un état pire que si j’avais cessé de marcher dessus, labourer indépendamment des drapeaux rouges peut conduire à des échecs très complexes. Traiter les problèmes dès que possible. Gardez un court compte.

Ne pas manipuler les erreurs conduit à :

• Un code fragile et rempli de bugs difficiles à trouver.
• Un code non sécurisé. Les crackers exploitent souvent une mauvaise gestion des erreurs pour pénétrer les systèmes logiciels.
• Une mauvaise structure. S’il y a des erreurs de votre code qui sont fastidieuses à traiter continuellement, vous avez probablement une mauvaise interface. Exprimez-le afin que les erreurs soient moins intrusives et que leur manipulation soit moins onéreuse.

Tout comme vous devriez vérifier toutes les erreurs potentielles dans votre code, vous devez exposer toutes les conditions potentiellement erronées dans vos interfaces. Ne les cache pas, en prétendant que tes services fonctionneront toujours.
Pourquoi ne vérifions-nous pas les erreurs ? Il y a un certain nombre d’excuses courants.

Avec lesquels êtes-vous d’accord ? Avec lesquels êtes-vous contre ?

• La gestion des erreurs perturbe le flux du code, le rend plus difficile à lire et rend plus difficile l’identification du flux d’exécution «normal».
• C’est un travail supplémentaire, et j’ai une échéance imminente.
• Je sais que cet appel de fonction ne renverra jamais une erreur (printf fonctionne toujours, malloc renvoie toujours une nouvelle mémoire, si elle échoue, nous avons de plus gros problèmes …).
• Ce n’est qu’un programme de jouets et n’a pas besoin d’être écrit à un niveau de production digne.