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');}.
Renvoyer null ne donne aucune information sur le type d'erreur ayant mené à ce résultat, c'est donc insuffisant. Par exemple, on pourrait imaginer que l'id soumis est trop grand, vide, ou qu'il ne correspond à rien.
Seule la méthode getMachinById() doit connaitre la nomenclature d'un Id, sinon chaque méthode appelante va dupliquer le code de validation d'un id.
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.
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.
[^] # Re: .
Posté par fredoche . En réponse au journal Le point sur Java 7. Évalué à 2.
Renvoyer null ne donne aucune information sur le type d'erreur ayant mené à ce résultat, c'est donc insuffisant. Par exemple, on pourrait imaginer que l'id soumis est trop grand, vide, ou qu'il ne correspond à rien.
Seule la méthode getMachinById() doit connaitre la nomenclature d'un Id, sinon chaque méthode appelante va dupliquer le code de validation d'un id.
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.
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.