Stratégie de gestion des exceptions
La gestion des exceptions n’est pas souvent prise au sérieux. La plupart des développeurs ajoute un bloc que try/catch seulement pour contenter le compilateur et laisse souvent le bloc catch vide.
Pourtant, l’utilisation des exceptions pour la gestion des erreurs se révèle être un outil très puissant lorsqu’il est bien utilisé. Julien Carnelos propose justement un guide sur la gestion des exceptions.
Selon lui, il existe quatre modes d’utilisation des exceptions :
- Algorithme de décision : l’exception levée nécessite l’exécution de code traitant l’erreur spécifique à l’exception.
- Rethrow : lever une exception encapuslant celle qui vient d’être levée. Souvent ce traitement est inutile. Sauf si l’on souhaite masquer l’implémentation sous jacente[1] ou que la nouvelle exception possède une réelle valeur ajoutée.
- Fail fast : laisser remonter l’exception jusqu’à l’utilisateur. Celà permet d’identifier au plus tôt les exceptions incontrôlées.
- Legacy : beaucoup de programme utilisent ce mode de fonctionnement où les exceptions sont attrapées mais rien n’est traité. Ce type de gestion est à proscrire ! Car il ne permet pas d’identifier les causes d’erreur facilement. Sans modifier ces applications pour les passer en Fail Fast, il est possible de tracer les piles d’exception[2].
Le Fail Fast représente vraiment un cas de bonne utilisation de la gestion des exceptions. Comme évoqué dans mon billet sur les modèles d’anti-conception pour la gestion de exceptions, il faut lever une exception le plus tôt possible et l’attraper le plus tard possible[3].
Vous êtes maintenant armé pour utiliser toutes les capacités de la gestion des exceptions.
Notes
[1] Pour rendre les couches logicielles imperméables.
[2] Celà permet d’analyser le comportement de l’application sans tout réecrire et sans provoquer d’effet de bord.
[3] L’idéal étant de l’attraper dans la couche de présentation pour l’afficher.
Laisser un commentaire