Mathieu Szablowski

Exceptions...

Exceptions...

Lors d’une conversation, nous sommes rentrés en conflit mon interlocuteur et moi au sujet du traitement des exceptions.

Celui-ci recourait systématiquement à un MessageBox.Show() afin d’informer l’utilisateur que son action avait échouée et de la raison de cet échec. Me demandant, pourquoi il ne fallait pas recourir à ce genre de reflexe, je lui ai cité un premier exemple.


Durant le développement d’un intranet de gestion de production, l’ensemble de l’équipe de développement avait jugé bon d’informer l’utilisateur des erreurs qui surgissaient lors des différents accès aux données.
15 jours de mise en pré-production plus tard, l’étude des logs de l’application présenta une situation pour le moins surprenante : "Une seule personne s’était connectée à l’application, mais celle-ci s’était connectée une quarantaine de fois".

En fait, lors d’un dépannage, nous avions demandé à l’utilisatrice de se connecter à l’aide d’un autre compte. Le problème en question était une erreur dans la gestion des droits et le problème fut rapidement résolu. Cependant, face aux erreurs semblables (même message d’erreur) que rencontraient certaines de ses collègues, cette personne leur a recommandé de se connecter avec un couple login/mot de passe qui fonctionnait beaucoup mieux :D .

En cas d’exceptions donc, il ne faut pas prévenir l’utilisateur de la cause de l’exception, juste des conséquences que cela entraîne.

Cette anecdote n’a vraiment suffit à convaincre mon interlocuteur et celui-ci me posa implicitement des questions essentielles auxquelles, il est vrai, j’ai eu du mal à répondre de façon claire et concise.

Profitant du week-end, je me suis plongé dans mes bouquins et notamment "Conception et Programmation Orientées Objet" de Bertrand Meyer. Ce dernier présente tout un chapitre à la définition et au traitement des exceptions.

Voici donc les questions et ce que je peux en retenir :

Qu’est-ce qu’une exception ?

 Il faut d’abord définir ce qu’est un échec. Il s’agît tout simplement du cas où une partie de l’application ne sait pas ou ne peut pas remplir son rôle. Cette échec intervient à l’exécution et est causé par une exception. Une exception est donc un évènement provoquant l’échec de la méthode due à un état anormal du système.

Que signifie traiter l’exception ?

Traiter l’exception consiste dans un premier temps à identifier l’exception, sa nature, en soit, ce qui a changé dans le système pour provoquer un échec.
Dans un second temps, il faut adapter la méthode (B Meyer parle de routine) afin que celle-ci tente de remplir son rôle.

Alors mon interlocuteur a-t-il réellement traité l’exception en informant l’utilisateur qu’une exception a eu lieu et que l’action a échoué ?

Oui, en partie, il a identifié l’exception et assure ainsi la survie de l’application (pas de crash) et l’intégrité des résultats (aucun résultat renvoyé donc pas de résultat inattendu).
Cependant, le simple fait de renvoyer un message d’erreur à l’utilisateur revient à baisser les bras face au problème "tenter de modifier la méthode pour qu’elle tente de remplir son rôle".
 Cette mauvaise habitude l’incite à ne jamais tenter de résoudre le problème. Nous sommes d’accord qu’il sera toujours délicat de modifier une méthode pour que celle-ci accède à un fichier qui n’existe pas ou bien qu’elle tente une division par zéro. Cependant, un certain nombre d’exception est gérable et le fait de se poser la question incitera à créer des fichiers secondaires ou à s’assurer que la variable ne contienne jamais 0.

En conclusion, on peut dire qu’une exception n’est pas une erreur et encore moins un simple évènement dont il faut avertir l’utilisateur. Il faut aussi tenter de gérer cette situation afin que l’application puisse remplir son rôle dans un maximum de circonstaces.