[sdx-developers] SDX 2 : gestion des exceptions

[Martin Sévigny]

Bonjour,

Voici quelques réflexions au sujet de la gestion des exceptions dans la
nouvelle version de SDX.

Principe 1 : ne pas laisser d'exception de bas niveau

Il faudrait encapsuler le plus possible les exception de style
"FileNotFoundException" ou "SQLException". Celles-ci donnent rarement
des messages d'erreurs satisfaisants. En d'autres mots, les exceptions
lancées devraient toujours devenir des exceptions SDX.

Principe 2 : différencier les exceptions système des exceptions
application/utilisateur

Une erreur causée par le SGBD qui ne répond pas n'est pas de la même
nature qu'une erreur qui est causée par une mauvaise requête d'un
utilisateur. Même si la frontière n'est pas toujours facile à délimiter,
toutes les exceptions SDX seront soit "internal", soit "application",
soit "user".

L'idée derrière cette approche est qu'une interface utilisateur devrait
(selon moi) rendre visible les messages d'erreur utilisateur mais pas
les messages d'erreur système. Ceux-ci devraient être remplacés par des
phrases génériques telles que "Une erreur interne nous empêche de donner
suite à votre demande ; veuillez réessayer plus tard ou contacter
l'administrateur". Quand aux erreurs applications (par exemple afficher
les valeurs d'un champ qui n'existe pas), c'est à l'application de
voir...

Principe 3 : coder les messages d'erreur

D'un strict point de vue de la programmation, c'est normal de procéder
ainsi, pour faciliter la gestion des messages d'erreurs.

Principe 4 : rendre public les codes d'erreur

Ce principe s'appuie sur le précédent, et vise à permettre aux
applications de gérer intelligemment les erreurs. Il faudrait avoir une
série de codes qui identifient le type d'erreur, un peu comme en HTTP où
il y a le 404, le 503, etc. Ainsi, une application ne recevrait pas
seulement un message d'erreur, mais aussi un code, stable et public, qui
permettrait de réagir différemment pour différents types d'erreurs.

Principe 5 : journaliser les exceptions

Toutes les exceptions devraient se retrouver dans le fichier log, avec
une sévérité "error".

Principe 6 : internationaliser les messages d'erreur

Bien sûr. On livrera une version anglaise et une version française.

Principe 7 : utiliser le locale système pour les fichiers logs

Les sorties dans le fichier log devraient être dans la langue de la
machine virtuelle Java. Si non disponible, elles devraient être dans la
langue par défaut, qui sera ... ?

Principe 8 : rendre disponible le contenu des exceptions aux
applications

Les exceptions SDX devraient être interceptées en XSP pour produire un
XML adéquat. Ce XML devrait comprendre les messages d'erreur en
différentes langues. Toutes? A voir.

OK, je pense que c'est tout pour les principes. Commentaires bienvenus
évidemment.

Martin Sévigny