De par mon expérience, j'ai noté plusieurs points.
La gestion d'erreur par « return code_erreur; » (où code_erreur est un nombre négatif, nul ou encore NULL) est inefficace. Le soucis étant qu'il est pénible d'écrire « if (resultat < 0) » ou « if (!result) » après chaque appel de fonction. Testez-vous le résultat de fopen() et de malloc() ? Si oui : très bien. Mais le faites vous pour snprintf(), write(), etc. ? Pour éviter de « polluer le code », on préfère supposer que les erreurs n'arrivent jamais. Le plus pénible est de diffuser l'erreur est fonctions parentes : si a() appelle b() qui appelle c(), et qu'une erreur intervient dans c() : il faut transmettre l'erreur à b() puis à a().
Du coup, les exceptions sont une vraie révolution pour la gestion d'erreur : toutes les erreurs sont remontées. Au pire, le code gérant l'erreur peut l'ignorer, mais dans ce cas, c'est volontaire. De plus, les erreurs sont typées et on peut créer une hiérarchie des types d'exception. Ceci permet d'écrire une gestion d'erreur générique.
Enfin, on peut décaler (déplacer) la gestion d'erreur : pour reprendre mon exemple précédent, l'erreur dans c() n'a pas besoin d'être transmis par b() ou a(), c'est automatique. De plus, on peut très bien écrire un gestion d'erreur très générique dans la fonction main() puis des gestions plus ciblés autour d'appels plus spécifiques. On ne va pas s'occuper des erreurs MemoryError après chaque appel de fonction, on va le gérer une seule fois dans main() par exemple.
# Vive les exceptions !
Posté par Victor STINNER (site web personnel) . En réponse au journal Qu'est-ce que bien gérer les erreurs dans ses programmes ?. Évalué à 9.
La gestion d'erreur par « return code_erreur; » (où code_erreur est un nombre négatif, nul ou encore NULL) est inefficace. Le soucis étant qu'il est pénible d'écrire « if (resultat < 0) » ou « if (!result) » après chaque appel de fonction. Testez-vous le résultat de fopen() et de malloc() ? Si oui : très bien. Mais le faites vous pour snprintf(), write(), etc. ? Pour éviter de « polluer le code », on préfère supposer que les erreurs n'arrivent jamais. Le plus pénible est de diffuser l'erreur est fonctions parentes : si a() appelle b() qui appelle c(), et qu'une erreur intervient dans c() : il faut transmettre l'erreur à b() puis à a().
Du coup, les exceptions sont une vraie révolution pour la gestion d'erreur : toutes les erreurs sont remontées. Au pire, le code gérant l'erreur peut l'ignorer, mais dans ce cas, c'est volontaire. De plus, les erreurs sont typées et on peut créer une hiérarchie des types d'exception. Ceci permet d'écrire une gestion d'erreur générique.
Enfin, on peut décaler (déplacer) la gestion d'erreur : pour reprendre mon exemple précédent, l'erreur dans c() n'a pas besoin d'être transmis par b() ou a(), c'est automatique. De plus, on peut très bien écrire un gestion d'erreur très générique dans la fonction main() puis des gestions plus ciblés autour d'appels plus spécifiques. On ne va pas s'occuper des erreurs MemoryError après chaque appel de fonction, on va le gérer une seule fois dans main() par exemple.