Erreurs courantes dans la gestion des exceptions

Une exception est une perturbation du flux normal d'exécution d'un programme Java (ou de tout autre). Cette violation peut survenir en raison d'une violation d'accès mémoire, d'une division par zéro, d'un problème d'initialisation, de l'exécution d'une instruction illégale ou de toute autre erreur fatale. Java est capable de gérer tous ces scénarios indésirables avec élégance, mais lorsqu'il s'agit d'utiliser ces fonctionnalités Java par les développeurs, plusieurs problèmes peuvent survenir. Dans cet article, je ne vais pas expliquer comment fonctionne la gestion des exceptions en Java. Je suppose que le lecteur est déjà familier avec la hiérarchie des exceptions, les exceptions vérifiées , les exceptions non vérifiées et les exceptions d'exécution . Nous discuterons ici des erreurs les plus courantes que vous devriez éviter.

Parties prenantes aux exceptions

Chaque fois que le fil d'exécution est interrompu, les informations le concernant doivent être renvoyées à l'exécuteur du programme. Ce fil peut démarrer depuis l'écran, depuis une tâche batch ou de toute autre manière. Tous ces déclencheurs attendent une sorte de violation dans le flux pour transmettre un message d'un certain format. Un déclencheur basé sur un écran peut nous faire savoir en douceur qu'il y a des problèmes techniques et que nous devons contacter l'assistance pour obtenir de l'aide et des conseils. Les processus par lots ou les programmes Java autonomes peuvent s'attendre à ce que le rapport d'erreur apparaisse sous la forme d'une sorte de journal totalement incompréhensible pour l'utilisateur final. Mais les hommes d’affaires doivent recevoir des messages dans une langue qu’ils comprennent. La redoutable NullPointerException dans l’esprit des utilisateurs est très ennuyeuse. Parfois, ces erreurs sont la conséquence d'une mauvaise utilisation du programme, mais parfois ce sont des problèmes qui nécessitent une correction. Le deuxième acteur important est celui qui devra faire face aux problèmes posés par les exceptions. Cette personne ne peut pas observer l'exécution réelle du programme lorsque l'exception se produit. Cela s'appuiera sur deux choses : premièrement, les informations fournies par l'utilisateur qui rencontre le problème, et deuxièmement, une sorte de journal généré lorsqu'une exception se produit. De plus, la personne qui analysera le problème n’est pas la même personne qui a écrit le programme et le développeur du programme doit donc fournir suffisamment d’informations pour l’analyse. Le seul moyen de communication entre le développeur du programme et son débogueur est un journal. De plus, parfois pour des raisons de sécurité, le journal peut ne pas contenir tous les détails réels de l'exécution du programme au moment où l'exception s'est produite. Examinons les erreurs possibles dans la gestion des exceptions. Certains d’entre eux ont l’air plutôt stupides, mais il y a des gens. qui n’y prêtent pas attention jusqu’à ce que ces erreurs entraînent des problèmes.

Bloc d'exception vide

C'est l'une des erreurs les plus indésirables dans la gestion des exceptions. Dans ce cas, l’exception est simplement ignorée. La solution ne contient rien d'autre qu'une ligne de commentaire pour laisser l'exception. try{ }catch(SQLException sqe){ // do nothing } Dans de rares cas, comme dans le bloc final lorsque la base de données est arrêtée, des exceptions peuvent être levées. Dans ce cas, ils peuvent être ignorés. try{ }catch(SQLException sqe){ ... ... }finally{ try{ conn.close(); }catch(Exception e){ //leave it. } }

Généralisation incorrecte du message d'exception

Ce point est subjectif. Après avoir détecté l'exception, vous pouvez la signaler à l'utilisateur final sous la forme d'un message convivial. Il est fort possible que les détails du message original soient perdus lorsque les messages originaux seront convertis en un message général. Le message doit transmettre les informations appropriées à l'utilisateur final afin que lorsqu'il contacte l'équipe d'assistance, l'utilisateur n'ait qu'à se connecter au journal approprié pour fournir les informations. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new Exception("File Processing Failed",ioe); } Dans une application multiniveau, chaque couche intercepte les exceptions et génère un nouveau type d'exception. Parfois, il est absolument nécessaire de lancer une exception d'un certain type : - Data Access Layer -> crée une DataAccessException - Business Implementation Layer -> crée une BusinessException - Application Service Layer -> crée une ApplicationServiceException Tout semble logique, n'est-ce pas ? Ici, nous devrons peut-être choisir entre ApplicationServiceException et BusinessException puisque les deux peuvent représenter les mêmes informations. L'une de ces conversions d'exception semble inutile.

Détruire la classe StackTrace

Au cours du processus de transformation d'une exception en un nouveau type spécial, la trace de la pile peut disparaître, ce qui rend la recherche de la cause réelle de l'exception un véritable cauchemar. Dans le code ci-dessous, vous pouvez voir comment une nouvelle exception est levée sans recevoir aucune information de l'exception d'origine. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new MyException("Problem in data reading."); }

Écraser le motif de l'exception

Chaque message d'exception contient des informations sur la raison de l'exception. Cependant, lorsqu'une nouvelle exception est créée, les informations concernant l'ancienne peuvent être définitivement supprimées. Ceci est similaire à l'exemple ci-dessus où StackTrace peut être supprimé en raison d'une nouvelle exception levée.

Pas de recherche d'exceptions spécifiques

Parfois, les développeurs aiment jouer la sécurité lors de la gestion des exceptions. Parfois, c'est facile à faire. Mais attraper java.lang.Exception au lieu d’une exception spécifique n’est pas acceptable. try{ File file = new File(""); file.getCanonicalPath(); }catch(Exception exe){ throw new MyException("Problem in data reading."); }

Attraper et lancer inutilement

Détectez les exceptions si vous souhaitez les convertir en un autre type ou si cela vous aide à ajouter des informations au message d'exception destiné à l'utilisateur final ou à l'analyste. Sinon, jetez-les simplement plus loin dans la signature de la méthode (en utilisant des lancers) au lieu de les attraper.

Attraper RuntimeException

Je recommanderais d'éviter d'attraper RuntimeException. Au lieu de cela, il est préférable de détecter les exceptions spécifiques et de les traiter.

Trouver des exceptions non vérifiées

La question de savoir s'il faut ou non détecter les exceptions non contrôlées est un sujet controversé. NullPointerException et ArrayIndexOutOfBound pourraient être les meilleurs exemples d'exceptions non vérifiées. Au lieu de détecter ces exceptions, vous pouvez modifier votre code pour gérer ces scénarios. Par exemple, pour éviter NullPointerException, pour s'assurer que toutes les variables sont initialisées, pour éviter les exceptions ArrayIndexOutOfBound, pour définir un tableau de la bonne longueur, etc.

Problèmes liés à la journalisation des exceptions

Le magazine aidera la deuxième personne intéressée, c'est-à-dire celle qui analyse le problème. Parfois, un développeur va trop loin avec les fichiers journaux et des journaux sont créés à chaque niveau de l'application. Le journal doit enregistrer l'exception au niveau auquel elle s'est produite. Il semble optimal d'afficher un avertissement indiquant qu'une exception s'est produite, avec une proposition d'arrêt ou de poursuite de l'exécution du programme, et une journalisation obligatoire de l'exception dans le journal.

Exception au contrôle de flux

Une exception est une perturbation du flux normal du programme, ce qui signifie que vous devez interrompre ce flux et en informer l'utilisateur final. Si nous ajoutons un appel de méthode qui est un thread alternatif, cela entraînera d'énormes problèmes de maintenance. try{ myObject.getValue(); }catch(NullPointerException npe){ alternateMethod(); }

Utilisation omniprésente de java.lang.Exception

Ce n'est pas non plus une bonne idée d'utiliser java.lang.Exception partout pour toute exception. Au lieu de cela, il est préférable d'utiliser des exceptions spécifiques à l'application ou les exceptions Java standard les plus appropriées. Article original : Erreurs courantes dans la gestion des exceptions Traduit et exprimé par : Ve4niY