J'ai une classe de modèle de domaine qui a une implémentation toString qui ressemble à ceci:
public String toString() {
try {
return getX() + "\n"
getY() + "\n"
getZ(); //etc.
} catch(Exception e) {
throw new RuntimeException(e);
}
}
Les méthodes getX(), getY()et getZ()ne sont pas accesseurs simples, ils peuvent effectuer des recherches en arrière - plan, en général une recherche à une carte statique de paires valeur de clé prédéfinie. Certains d'entre eux avaient throws SomeCheckedExceptiondans leurs signatures.
Mon impression est que c'est une mauvaise pratique et une « odeur de code ». Le fait que toString()même besoin de ce chèque est pour moi un symptôme d' une mauvaise conception. Mais je me demande par un collègue, ce qui ne va pas avec la capture générique exactement Exceptiondans un toString(), étant donné que la prise Exceptionse propage plus loin.
Je crois qu'il viole au moins le principe KISS, car une méthode simple comme toString()ici est indiquée comme nécessitant la gestion des exceptions spéciales.
Donc, est-il une odeur de code pour avoir un fourre-tout dans un bloc toString ()?
Les réponses que je trouvais étaient pour le scénario général de la capture générique Exceptionet je suis d' accord avec la plupart d'entre eux, que si vous faites un mécanisme de gestion des erreurs générique ou un lot alors il est prévu de travailler sur des exceptions génériques. Cet argument a été peu convaincant dans notre discussion, donc je suis curieux d'autres opinions.
Pour la toString()méthode, la capture Exception est pas nécessairement une mauvaise pratique. Cependant, re-jeter est la partie problématique.
Le contrat de toString () est:
... En général, la méthode toString renvoie une chaîne qui « représente textuellement » cet objet. Le résultat devrait être une forme concise mais représentation informative qui est facile pour une personne à lire ...
En Effective Java 3rd Edition (article 12), Bloch insiste également:
Lorsque cela est possible, la méthode toString doit retourner toutes les informations intéressantes contenues dans l'objet.
Donc, si cela exige d'appeler des méthodes qui peuvent lancer des exceptions vérifiées, alors qu'il en soit, et cela fait beaucoup de sens pour attraper ces exceptions.
Toutefois: exceptions vérifiées soulevées fournissent des informations sur l'état de l'objet. Constamment dans le but de toString, il peut être une bonne idée d'inclure l'état d' exception dans le message retourné par toString.
Quant à savoir pourquoi il est une mauvaise idée de jeter des exceptions à toString, ce poste offre une excellente réponse.
Recommandation: Attrapez les exceptions vérifiées à l' aide de leur type d'exception spécifique, et d' intégrer ce fait dans le toString()message, au lieu de le propager.