J'ai analysé le code que je travaille sur l'utilisation d'un analyseur de code source Java. L'un des avertissements est "toujours déclarer des exceptions définies par l'utilisateur en finale". Il y a beaucoup d'autres avertissements qui n'ont pas beaucoup de sens, mais celui-ci m'a rendu un peu confus.
Je travaille sur un cadre et j'ai une exception générique root (Say FrameworkGenericeXception) et pour d'autres exceptions, je les dérive simplement de l'exception racine. J'ai donc une hiérarchie d'exceptions pour le cadre. Je pourrais prolonger la hiérarchie, mais cet avertissement, je pense me dire de ne pas avoir une telle hiérarchie mais les définir individuellement. Alors, à quoi devrais-je aller, quels sont vos commentaires?
5 Réponses :
Je n'ai jamais entendu parler de cette recommandation, ni cela n'a aucun sens pour moi.
Quel outil utilisez-vous? J'ai essayé de googler pour ce message et j'ai eu des coups de zéro à l'écart de votre alors question. Essayer d'autres recherches dans la tentative de "exploiter la sagesse du filet" ne me donnait rien de manifestement pertinent non plus.
Peut-être que vous devriez demander aux auteurs de l'outil Analyseur de code d'expliquer la justification de cette règle de style ...
Ouais ... Ok si rien ne vient je le ferai et je vous laisserai les gars savoir;) Mais nous devrions faire un brainstorming avant de demander ...
étrange. Google ne montre qu'un seul document avec de tels mots - votre question :)
Dans mes projets, il est tout à fait normal d'avoir une ou des ancêtres définis par l'utilisateur pour toutes les exceptions. Quelques années de développement dans ce style, rien de spécial jusqu'à présent lié à cela.
La chose est, un outil d'analyse statique analyse essentiellement votre code pour violation de (ce que l'auteur de l'outil estime être) "meilleures pratiques". Dans ce cas, il est généralement considéré comme une "meilleure pratique" d'avoir des hiérarchies d'exception très peu profondes.
La raison en est qu'il y a essentiellement deux fois lorsque vous attraperez une exception. Le premier, est que vous voulez attraper l'exception car vous savez comment le gérer em>. Par exemple: P> try
{
doStuff();
catch(Exception e)
{
logException(e);
notifyUser(e);
}
Si c'est ce qu'ils essaient de faire, ils y vont de la mauvaise manière. En outre, je pense que le vrai problème est que vous ne devriez pas être paresseux et tout déclarer comme jetant l'exception racine. IMO, la profondeur de la hiérarchie est immatérielle.
Raison de FrameworkGenericException Par exemple: SQLException (dire qu'une exception spécifique provient des API sous-jacentes qui ne peuvent pas être récupérables). Donc, cette exception spécifique est blindée. Les clients de ce cadre n'ont pas besoin de savoir sur l'exception spécifique, mais ils obtiennent à la place à la même manière que la framewaregenericercepxception comme une exception rien à faire. Mais s'ils deviennent quelque chose, étend quelque chose de fabriquegenercepxception, il devient significatif. Et les exceptions BTW n'ont que deux niveaux de dérivation.
Je pense qu'il n'y a rien de mal à créer une hiérarchie d'exceptions, cela facilite le programme de comprendre et de travailler avec. Voir ma réponse, j'ai fourni un exemple pour cela.
@erdogany: Dans ce cas, j'aurais deux exceptions distinctes et non héritantes. Une classe d'exception non cochée (qui hérite de RunTimeException ) pour encapsulation sqléxception (que le code client ne peut pas gérer) et une exception vérifiée (qui hérite directement de exception ) pour le quelque choseNotFoundException . Cependant, c'est juste mon opinion pour comment i feriez et vous êtes libre de le faire comment vous s'il vous plaît.
Ceci est probablement la pratique standard pour eux: Déclarez des cours comme final si elles ne sont pas censées être héritées de, et ils pensent aussi que toutes vos exceptions ne seront pas prolongées.
Cependant, dans votre cas Je pense que c'est une bonne chose à faire une exception générique et à prolonger toutes les autres. Dis, vous avez: p> où ces exceptions sont des sublasses de imageworkexception code>. Alors vous pouvez gérer des exceptions un peu plus facilement. P> try {
frameworkMethod();
} catch (FrameworkException ex) {
logger.log(Level.SEVERE, "An exception occured!", ex);
if (ex instanceof IllegalDataException) {
// Do something to recover
} else if (ex instanceof InvalidCommandException) {
//Inform the user
} //And so on...
}
@Malcom C'est exactement ce que je fais ... et seulement dans quelques cas ce genre de si / sinon
Oui, je pensais qu'il serait préférable d'illustrer pourquoi il peut être pratique d'avoir un arbre d'exception et non seulement une exception par un cas très spécial.
Très courant d'avoir une exception Ourdomaine pour permettre une classification facile.
Je parierai que ce message disparaît si vous faites votre exception générique abstraite. Vous suivrez un autre gourou bien respecté orienté objet, Scott Meyer:
Faire des classes non-feuilles abstraites.
Personnellement, je ne suis pas d'accord avec une exception racine pour tout votre framework. Quel comportement extraordinaire avez-vous intégré que tous les enfants hériteront de savoir ce qui vient de
java.lang.themble ?Je pense avoir
spécialbusinessexception Remplacer les quatre constructeurs à partir dejava.lang.runtimeException est beaucoup. Quel est le point de la hiérarchie? Je parierai qu'il est plat et large, avec une classe de racine. Pourquoi déranger?
Permettre aux captures de niveau supérieur d'identifier clairement s'il s'agit d'une exception de fournisseur ou non?
Je pense que le nom du paquet de fournisseur devrait suffire. De combien plus d'indication avez-vous besoin?
Je rejoint votre confusion, cette suggestion ne semble pas avoir beaucoup de sens.
Quel est l'analyseur de code source? Est-ce généralement disponible pour les autres?
Il s'agit d'IBM Rational Software Analyzer est livré sous forme de plug-in avec le développeur d'applications rationnelles (une IDE basée sur l'éclipse)
Chaque fois que vous traitez avec des analyseurs de code, prenez des suggestions avec un grain de sel: après tout, l'opinion de quelqu'un d'autre est codée dans un "avertissement"
ibm.com/developerworks/forums/thread.jspa?ThreadId=349744 < / a>