En l'occurence, la méthode getMachinById() se doit de renvoyer une MachinNotFoundException, simplement parce qu'un catch(MachinNotFoundException mnfe) {...} est mille fois plus explicite qu'un if(machin !null) {...} qui lui n'impose pas de else {log.error('oulalala');}.
Tu semble considérer que ne pas trouver ton machin est une erreur.
Moi ça me semble plutôt un comportement tout à fait normal, on cherche un certain machin, si on le trouve on en fera quelque chose sinon on fera autre chose.
C'est au code appellant de savoir si ne pas trouver de machin est une erreur (le machin aurait du être là) où une situation normale.
Seule la méthode getMachinById() doit connaitre la nomenclature d'un Id
Ça c'est un autre problème, si l'ID a une nomenclature particulière et n'accepte pas n'importe quelle valeur il faut que la méthode lance une exception (genre IllegalArgumentException) si la valeur passée est invalide.
Mais si la valeur passée est acceptable, il ne faut pas lancer d'exception simplement parce qu'on ne trouve rien.
Image la classe Map qui lancerait une exception dans son get simplement parce que la clé donnée n'est pas présente dans le Map (d'autant que certaines implémentations acceptent null en valeur, et peuvent donc retourner null même si la clé est présente).
L'argument des performances pour la gestion des exceptions est fallacieux. Les exceptions ça va vite, et bien que ce soit verbeux, c'est lisible.
Lancer une exception nécessite de construire le stacktrace de l'endroit qui a lancé l'exception (souvent quelque dizaines de StackTraceElement), ça me semble quand même significativement plus lourd que de simplement retourner null (quand c'est pertinent par rapprot à la sémentique de la méthode) qui ne va allouer aucune mémoire.
Les exceptions ne sont pas là pour indiquer que le programme va partir en sucette à partir de maintenant. Elles sont là pour rendre plus clair le déroulement d'un programme.
On n'a vraisemblablement pas la même notion de clareté d'un code.
[^] # Re: .
Posté par wismerhill . En réponse au journal Le point sur Java 7. Évalué à 2.
Tu semble considérer que ne pas trouver ton machin est une erreur.
Moi ça me semble plutôt un comportement tout à fait normal, on cherche un certain machin, si on le trouve on en fera quelque chose sinon on fera autre chose.
C'est au code appellant de savoir si ne pas trouver de machin est une erreur (le machin aurait du être là) où une situation normale.
Seule la méthode getMachinById() doit connaitre la nomenclature d'un Id
Ça c'est un autre problème, si l'ID a une nomenclature particulière et n'accepte pas n'importe quelle valeur il faut que la méthode lance une exception (genre IllegalArgumentException) si la valeur passée est invalide.
Mais si la valeur passée est acceptable, il ne faut pas lancer d'exception simplement parce qu'on ne trouve rien.
Image la classe Map qui lancerait une exception dans son get simplement parce que la clé donnée n'est pas présente dans le Map (d'autant que certaines implémentations acceptent null en valeur, et peuvent donc retourner null même si la clé est présente).
L'argument des performances pour la gestion des exceptions est fallacieux. Les exceptions ça va vite, et bien que ce soit verbeux, c'est lisible.
Lancer une exception nécessite de construire le stacktrace de l'endroit qui a lancé l'exception (souvent quelque dizaines de StackTraceElement), ça me semble quand même significativement plus lourd que de simplement retourner null (quand c'est pertinent par rapprot à la sémentique de la méthode) qui ne va allouer aucune mémoire.
Les exceptions ne sont pas là pour indiquer que le programme va partir en sucette à partir de maintenant. Elles sont là pour rendre plus clair le déroulement d'un programme.
On n'a vraisemblablement pas la même notion de clareté d'un code.