Il y a quelques règles de gestion des exceptions que vous devez garder à l'esprit. Mais d'abord, vous devez vous rappeler que les exceptions font partie de l'interface exposée par le code; les documenter . Ceci est particulièrement important lorsque l'interface est publique, bien sûr, mais c'est également une très bonne idée dans les interfaces privées.
Les exceptions ne doivent être gérées qu'au point où le code peut faire quelque chose de sensé avec elles. La pire option de manipulation est de ne rien faire du tout à leur sujet, ce qui ne devrait être fait que lorsque c'est exactement la bonne option. (Lorsque j'ai une telle situation dans mon code, j'inclus un commentaire à cet effet afin que je sache ne pas m'inquiéter du corps vide.)
La deuxième pire option consiste à lever une exception sans rapport avec l'original attaché comme cause. Le problème ici est que les informations dans l'exception d'origine qui permettraient de diagnostiquer le problème sont perdues; vous créez quelque chose avec lequel personne ne peut rien faire (à part se plaindre que «cela ne fonctionne pas», et nous savons tous comment nous détestons ces rapports de bogues).
Il est beaucoup mieux de consigner l'exception. Cela permet à quelqu'un de découvrir le problème et de le résoudre, mais vous ne devez enregistrer l'exception qu'au point où elle serait sinon perdue ou signalée via une connexion externe. Ce n'est pas parce que la journalisation plus souvent est un problème majeur en tant que tel, mais plutôt parce qu'une journalisation excessive signifie que le journal consomme plus d'espace sans contenir plus d'informations. Une fois que vous avez enregistré l'exception, vous pouvez signaler une décision précise à l'utilisateur / client avec bonne conscience (tant que vous incluez également l'heure de génération - ou un autre identifiant de corrélation - dans ce rapport afin que la version courte puisse être mise en correspondance avec le détail si nécessaire).
La meilleure option est, bien sûr, de gérer complètement l'exception, en traitant la situation d'erreur dans son intégralité. Si vous pouvez le faire, faites-le! Cela peut même signifier que vous pouvez éviter d'avoir à enregistrer l'exception.
Une façon de gérer une exception consiste à lever une autre exception qui fournit une description de niveau supérieur du problème (par exemple, " failed to initialize" au lieu de " index out of bounds"). C'est un bon schéma tant que vous ne perdez pas les informations sur la cause de l'exception; utilisez l'exception détaillée pour initialiser l' causeexception de niveau supérieur ou enregistrez le détail (comme expliqué ci-dessus). La journalisation est plus appropriée lorsque vous êtes sur le point de traverser une frontière inter-processus, comme un appel IPC, car il n'y a aucune garantie que la classe d'exception de bas niveau sera présente du tout à l'autre extrémité de la connexion. Le maintien en tant que cause attachée est le plus approprié lors du franchissement d'une frontière interne.
Un autre modèle que vous voyez est le catch-and-release:
try {
// ...
} catch (FooException e) {
throw e;
}
Il s'agit d'un anti-modèle, sauf si vous avez des contraintes de type provenant d'autres catchclauses, ce qui signifie que vous ne pouvez pas laisser passer l'exception par elle-même. Ensuite, ce n'est qu'une laideur de Java.
Il n'y a pas de réelle différence entre les exceptions vérifiées et celles non vérifiées, à part le fait que vous devez déclarer les exceptions vérifiées qui franchissent les limites des méthodes. C'est toujours une bonne idée de documenter les exceptions non contrôlées (avec le @throwscommentaire javadoc) si vous savez qu'elles sont délibérément levées par votre code. Ne jetez pas délibérément java.lang.Errorou ses sous-classes (sauf si vous écrivez une implémentation JVM).
Avis: Un cas d'erreur inattendue représente toujours un bug dans votre code. Les exceptions vérifiées sont un moyen de gérer cette menace, et lorsque les développeurs utilisent délibérément des exceptions non contrôlées pour éviter les problèmes de gestion des cas d'erreur, vous accumulez beaucoup de dettes techniques que vous devrez nettoyer un certain temps si vous voulez du code robuste. La gestion des erreurs bâclée n'est pas professionnelle (et regarder la gestion des erreurs est un bon moyen de déterminer à quel point un programmeur est vraiment bon).