Les exceptions sont très utilisées. Pourtant, il n’est pas toujours évident de savoir comment les gérer correctement.

Tim McCune a écrit un article intitulé Exception-Handling Antipatterns où il présente les modèles d’anti-conception sur le traitement des exceptions.

Cet article donne les réponses aux questions :

  • Faut-il créer ses propres exceptions ?
  • Quand faut-il lever une exception ?
  • Quand capturer une exception ?
  • …

De son étude, on peut retenir qu’il existe deux types d’exception à créer soi-même :

  • Quand un problème survient : elle est propre à la couche applicative.
  • Pour encapsuler et lever une exception rencontrée : elle est utilisé pour masquer l’implémentation sous-jacente.

Quelques cas d’anti-conception

De plus, il nous conseille de ne pas tracer puis lever une exception. En effet lors de la capture d’une exception, il faut soit la tracer soit la lever. Mais il ne faut pas faire ces deux actions en même temps, sous peine de rencontrer les piles d’exception en double (voir plus) dans les traces.

Il est très dangereux de capturer directement l’exception générique : Exception. En effet, si le code appelé est modifié et peut lever de nouvelles exceptions, il est possible de passer à côté de nouveaux cas d’erreur non gérés.

Il faut faire attention à l’utilisation de l’encapsulation d’exception pour ne pas perdre les informations transmises par l’exception source.

De même, il n’est pas conseillé de retourner null lors qu’une exception est rencontrée. Comme son nom l’indique, une exception est un cas exceptionnel. Il faut réserver l’utilisation de la valeur null pour les cas fonctionnels.

Le traitement d’une exception peut passer par l’exécution de code de finalisation. Ce code ne doit en aucun cas pouvoir lever une exception sous peine de perdre la cause réelle la première exception.

Parfois l’implémentation de certaines méthodes ne sont pas toujours disponible. Cela se traduit souvent par l’écriture d’une méthode qui retourne la valeur null. Il est préférable de retourner une exception expliquant que la méthode n’est pas implémentée.

La gestion des exceptions, par le traitement de la cause de l’exception, fragilise le code. En effet, lorsque l’on est pas maitre du code levant l’exception, la cause de l’exception peut changer si l’implémentation change. Le code appelant compilera toujours, pourtant le résultat à l’exécution n’est pas garanti !

Quelques conseils supplémentaires

Sur le même thème, Gunjan Doshi et Jim Cushing ont écrit respectivement les meilleures utilisations de la gestion des exceptions et trois règles pour la gestion des exceptions. Les auteurs insistent sur la différence entre les classes Throwable, Error, Exception et RuntimeException en Java.

J. Cushing explique également qu’il faut lever le plus tôt possible une exception. Et de la même manière, il faut capturer le plus tard possible une exception levée. Le fait de lever le plus tôt possible une exception la rend plus spécifique et donc plus explicite. Et en capturant le plus tard possible une exception, cela permet de bénéficier d’une pile d’exception plus complète et donc plus facile à analyser.

Conclusion

La prochaine fois que vous vous posez des questions sur la façon dont il faut concevoir la gestion des exceptions dans votre application, repensez à ces modèles d’anti-conception. Celà vous permettra d’éviter quelques pièges.

SeBConceptionDéveloppementconception,exception,javaLes exceptions sont très utilisées. Pourtant, il n'est pas toujours évident de savoir comment les gérer correctement. Tim McCune a écrit un article intitulé Exception-Handling Antipatterns où il présente les modèles d'anti-conception sur le traitement des exceptions. Cet article donne les réponses aux questions : Faut-il créer ses propres exceptions ? Quand faut-il lever une...Un blog, c'est un blog !