[TUTORIEL] COMMENT RÉAGIR FACE À UNE EXCEPTION
djo0012
Messages postés
4
Date d'inscription
mercredi 8 mars 2006
Statut
Membre
Dernière intervention
18 juillet 2011
-
18 juil. 2011 à 04:59
Utilisateur anonyme - 20 juil. 2011 à 17:13
Utilisateur anonyme - 20 juil. 2011 à 17:13
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/53375-tutoriel-comment-reagir-face-a-une-exception
https://codes-sources.commentcamarche.net/source/53375-tutoriel-comment-reagir-face-a-une-exception
20 juil. 2011 à 17:13
20 juil. 2011 à 13:41
Ce tutoriel ne parle pas du finally, c'est vrai mais il ne parle pas non plus du try et du catch. Il est destiné à traiter les erreurs de codage du développeur et ne donne pas de solution pour gérer les exceptions dans le code.
Vu les commentaires sur ce tutoriel, il n'est pas bon, j'accepte vos remarques et je vais essayer d'en proposer une version différente.
20 juil. 2011 à 12:58
En fait, même pour les exceptions de type NullPointerException, je ne suis pas d'accord, tester si c'est null ne suffit pas, il faut au moins mettre un message dans les logs si une méthode ne devrait pas être appelée avec un paramètre à null voire lancer une exception plus explicite encapsulant l'exception en question du genre throw new IllegalStateException("le prénom ne devrait jamais être à null",npe). C'est vrai pour les exceptions en général. Il faut choisir dans quelle couche on l'attrape et dans quelle couche on offre un traitement adapté.
Le tutoriel ne parle pas du tout du "finally".
Je pense que les débutants devraient surtout avoir le réflexe de lire la documentation Java.
Le dernier paragraphe sur OutOfMemoryError traite de la mémoire de manière très très superficielle, le conseil donné ne résoudra pas le problème si une augmentation de la mémoire non paginée aurait été plus adéquate et s'il n'est pas possible d'augmenter la taille passée à -Xmx de telle sorte que cette mémoire en accès direct soit suffisante.
18 juil. 2011 à 20:42
Vous avez raison, les exceptions ne sont pas forcément à éviter. Le but de ce tutoriel n'est pas d'apprendre comment gérer les exceptions mais permet de comprendre ce qui a mal été fait lorsque l'exception est levée lors de la phase de développement et est dû à une erreur du programmeur.
L'idée de faire ce tutoriel m'est venue en voyant que le forum était truffé de questions concernant les exceptions et leur signification.
Je vais essayer de tenir compte de vos remarques et je posterai avant la fin de la semaine une nouvelle version de ce tutoriel.
N'hésitez pas à ajouter des choses si vous avez d'autres idées.
18 juil. 2011 à 19:32
Dans les cas des NullPointerException (et la plupart des Exceptions courantes), tester soi-même la nullité possible des arguments pour les lever avant le reste de la méthode (pour ne pas être dans un état instable).
Avec la bonne pratique de ne JAMAIS ignorer une exception :
- Soit réellement avoir quelque chose à faire dans le catch
- De la laisser passer au-dessus avec le marqueur "throws" de la méthode et en commentant correctement les cas en questions.
- D'encapsuler l'Exception "catchée" par une Exception personnalisée.
Ainsi que la bonne pratique d'englober la tâche entière dans la gestion dans le bloc try/catch.
18 juil. 2011 à 04:59
A tous:
les résolution donné ne permette pas de récupéré d'un exception mais seulement d'évité 'simplement' que l'Exception ne puisse arrivé ce qui n'est pas l'objectif des exception:
nullPointerException: généralement il y a un problème de logique derrière un null pointer qu'il ne faut masqué par un if(param!=null) exemple parfait que tu nous donne, si l'utilisateur veut changé sont mots de passe il ne faut _surtout_ pas silencieusement ne pas le changé parce que notre code n'a pas transmis le User
ClassNotFoundException, NoClassDefFoundException: il n'y a jamais d'Exception levé a la compilation par contre ClassNotFoundException peut effectivement être jeté lors de l'utilisation de JDBC pour un débutant sinon par utilisation de la réflexion par un utilisateur plus avancé, le problème peut effectivement provenir du classPath,mais vérifier aussi d'avoir écrit _exactement_ la bonne String dans le Class.forName
OutOfMemoryError: les exemple par rapport a la récursivité peuvent aussi causé un exception StackOverflow, de la meme manière sois il s'agit d'un problème avec le code (récursion infini) sois l'algorithme a réellement besoin d'une trop grande récursion auquel cas il vaut mieux le transformé de manière itérative, il sera aussi plus rapide si bien implémenté