Du bon usage des exceptions

Si nous intégrons tous la gestion des exceptions dans notre code source (enfin, je l’espère…), en faisons-nous vraiment bon usage ? Entre les « maniaco-dépressifs » qui en mettent partout et les « bricolo-codeurs » qui savent à peine les mettre en place, il y a un compromis… qui n’est pas toujours évident à trouver.

Erreur, dysfonctionnement et exception

Par définition, une exception n’est levée qu’en cas d’état exceptionnel de l’application. Le tout est d’arriver à définir l’état d’exception. Est-ce un dysfonctionnement applicatif grave (connexion à une base de données qui tombe, fichier applicatif introuvable, allocation mémoire excessive, objet corrompu) ? Est-ce un fonctionnement normal mais exceptionnel (erreur d’authentification utilisateur, données entrantes non conformes) ? Est-ce une situation fréquente mais ne répondant pas au scénario optimal d’utilisation (mauvaise utilisation de l’application, erreurs de saisie d’un utilisateur) ?

Après avoir vu tous les cas sur le terrain, mais aussi dans des documents de référence, j’avoue ne plus savoir où placer le curseur…

Réserver l’exception aux dysfonctionnements

Pour ma part, je préfère garder l’exception pour les situations les plus rares et les plus graves, ce que je définis comme des situations exceptionnelles. Elles sont généralement dues à des dysfonctionnements de l’application, c’est-à-dire des états qui n’ont pas été prévus dans les séquences d’utilisation.

Sur ce principe, une erreur de saisie d’un utilisateur ne devrait jamais déclencher une exception lorsque sa valeur est contrôlée par l’application. Si j’entre une adresse e-mail invalide dans un formulaire, l’application traitera l’événement comme une erreur utilisateur et non comme un dysfonctionnement interne. Elle retournera le formulaire avec un joli message d’erreur… qui n’a rien d’exceptionnel puisque ce traitement fait partie du fonctionnement normal de l’application (mais pas de sa séquence nominal !). Même si cela semble évident (pour moi, du moins…), l’utilisation des exceptions pour ces cas est loin d’être anecdotique.

Bien sûr, si après validation de l’adresse e-mail l’application ne peut pas traiter normalement le formulaire, l’utilisation des exceptions permettra de trouver l’origine du dysfonctionnement, sans mettre les données dans un état inconsistant.

Trouver le bon équilibre

Dans le cas d’applications complexes où la modularité de code est de rigueur (genre « full MVC avec intégration de tous les designs patterns du GoF » !), savoir instancier puis récupérer une exception au meilleur endroit (ou moment pour les aficionados de la programmation événementiel) est déjà moins évident. Quels rôles jouent les différents niveaux de la partie M (modèle) ? Comment réagit la partie C (contrôleur) ? Comment gérer efficacement l’imbrication des exceptions (du noyau à l’interface en passant par les couches métiers) sans perturber la compréhension du problème par l’utilisateur ? Bien sûr, chaque cas est particulier, mais j’avoue que je souhaiterais bien discuter du sujet, autour de vos expériences.

Je vous passe la main !