Si les exceptions sont un véritable progrès dans l'écriture du code, elles ne sont en aucun cas synonymes ni de facilité, ni de robustesse.

A l'époque de la préhistoire, c'est-à-dire il y a quelques décennies à peine, l'instruction goto sévissait cruellement et les programmes spaghetti, inextricables, totalement incompréhensibles et illisibles, souvent écrits par des scientifiques plutôt que des informaticiens, étaient partout. Puis, il fut démontré qu'il est possible d'écrire un programme sans aucun goto et globalement le code se trouva assaini, écrit plus vite, et avec plus de sûreté. Néanmoins, le code constitué de tests imbriqués avec des codes d'erreur qui doivent remonter plusieurs appels de fonction, devient vite un pensum lui aussi, long à concevoir et à mettre au point. C'est ici qu'arrivent les exceptions. Celles-ci sont un véritable progrès, car elles permettent d'écrire le code plus vite, et avec plus de clarté, en faisant facilement remonter une condition d'erreur à toute une pile d'appels. Tel est leur bon aspect. Mais des exceptions utilisées avec insouciance, par paresse ou facilité peuvent vite devenir de fausses amies, génératrices de problèmes subtils. Ecrire du code (qui marche :) a toujours été et restera difficile. En l'occurrence, parce qu'elles brisent le flux d'exécution, les exceptions ont un petit quelque chose du goto de la préhistoire, qui, masqué, vient prendre sa revanche. Essayons de le déjouer. Commençons avec Java.

Frédéric Mazué