Provider pour Exception : ExceptionMapper

Dans le cadre d’un projet scolaire, nous avons mis en place une application Java EE contenant des EJBs et des WebServices REST. Dans nos EJBs, nous avons créé une gestion d’erreurs par exceptions pour avoir des retours notamment en ce qui concerne la base de données. Afin d’obtenir un message claire et orienté utilisateur, nous avons paramétré une classe Provider héritant de ExceptionMapper gérant les Exceptions de manière personnalisée avant de les envoyer aux clients légers. Ainsi, l’utilisateur ne sera pas bloqué sans information, et celles qui lui sont envoyées sont formatées pour avoir un affichage propre.javaProviderException

L’objectif de ce Provider est donc de récupérer toutes les exceptions levées par l’application et de les traiter en fonction de leur origine. Si cette exception est personnalisée, elle contient déjà les informations relatives à son niveau de gravité et un message d’erreur associé, il suffit donc de transmettre le message avec le code HTTP correspondant. En revanche si l’exception n’est pas gérée par notre code, nous ne souhaitons pas que l’utilisateur recoive un message indiquant « NullPointerException« . Nous allons donc gérer ce cas en ajoutant cette erreur aux logs de l’application pour correction et en envoyant un message avec le code HTTP 500 Internal Server Error. Du coté client, ces différentes erreurs peuvent donc être traitée différement grâce aux codes HTTP.

La classe

Notre classe ExceptionProvider implémente la classe ExceptionMapper avec pour paramètre générique la classe Exception. Ceci veut dire qu’elle va être appelée pour toutes les exceptions dérivées de la classe Exception, soit toutes les exceptions. Une limitation peut être faite à ce niveau selon le type d’exception que l’on veut traiter dans cette classe. Cette classe est annotée avec @Provider, elle sera ainsi automatiquement détectée et chargée lors du démarrage de l’application. Enfin, elle possède une unique méthode toReponse() qui définit le traitement à effectuer avec l’exception.

La méthode

Dans notre méthode, nous avons tout d’abord un premier test. Ce test va déterminer si l’exception levée est une exception personnalisée ou si elle n’est pas gérée dans notre code. Si elle est gérée, nous allons alloué un statut HTTP particulier correspondant à l’erreur et transmettre le message (contenant une description de l’erreur et l’exception d’origine s’il y en a une). Si elle n’est pas gérée, alors nous allons écrire dans les logs l’erreur détectée et transmettre un message générique. Ici, la réponse est renvoyée en JSON mais elle peut être formattée dans différents formats.

Ce modèle est celui que nous avons appliqué dans notre projet et n’est pas forcément applicable à toutes les situations. Il est à adapter à chaque cas d’utilisation.

Finalement

Dans le cadre d’une utilisation des EJBs, les exceptions levées sont automatiquement englobées au sein d’une EJBException. Dans notre test, il faut donc tester l’exception-cause. La clause instanceof permet de valider le test pour toutes les instances de la classe MessageException mère et toutes les classes dérivées. Nous avons attibué aux niveaux de criticité de notre application des statuts HTTP afin que le développeur Frontend puisse connaitre la dangerosité de l’erreur: INTERNAL_SERVER_ERROR pour des erreurs internes non gérées ou bloquantes, FORBIDDEN pour des erreurs métiers, UNAUTHORIZED pour une limitation des droits de la session actuelle ou une session expirée.

Coté JavaScript

Notre application étant accessible par des WebServices, les appels Ajax sont très utilisés et voici un exemple de comment gérer les différents types d’erreurs.

spacer

Laisser un commentaire