Je vous propose de revoir quelques mauvaises pratiques rencontrées lors de la gestion des exceptions.
1 – Logger et rejeter
Description
Il s’agit içi de logger et rejeter à la fois une exception. Le problème vient de la redondance d’information que peut entraîner ce genre de pratiquer, on finit par polluer les logs de messages similaires et non pertinents.
try
{
//my code here
} catch (AnException e){
Logger.log(e);
throw e;
}
Solution
Soit logger l’exception soit la rejeter avec un message + l’exception d’origine mais pas les 2.
2 – Jeter une exception de type Exception
Description
Très mauvaise pratique, en procédant de la sorte , le code est appauvri et aucune information n’est véhiculé il est préférable de jeter des exceptions spécifiques à un problème. De plus vous obligez les clients utilisateurs de votre code à catcher la classe Exception qui est une autre mauvaise pratique décrite plus bas.
Certains pourraient être tenté de faire comme cela pour gagner du temps mais croyez moi le code n’en sera que plus complexe à maintenir.
public void foo () throws Exception {
Solution
Si vous avez une méthode qui est un susceptible de lever une checked exception il est préférable de la lever clairement et si votre methode potentiellement lève plus d’une exception alors vous pouvez soit toutes les déclarer après la clause throws ou alors les réunir sous une super classes si elles cela a du sens, vous gagnerez ainsi en visibilité.
3 – Catcher la classe Exception
Description
Catcher la super class Exception est une très mauvaise pratique car vous traiter toutes les exceptions (checked et unchecked exception) de la même manière.
Techniquement cela veut dire que même les exceptions de type RuntimeException seront catchées en clair un NullPointerException sera traitée comme une checked Exception ce qui est complètement absurde car on ne peut rétablir suite à un NPE.
De plus cette façon de procéder vous prive potentiellement de détecter les futures changements qui pourraient avoir lieu dans le code appelé.
En effet si on venait a modifier la méthode en question par exemple en y ajoutant une autre checked exception, du point de vue de votre code vous ne seriez pas du tout averti.
public void bar()
{
try
{
//code here
} catch (Exception e){}
}
Solution
Il impératif de ne catcher que l’exception ou les exceptions spécifique(s) jetée(s) par la méthode sous peine de tomber dans les problèmes évoqués ci dessus.