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.