Quelle est la règle générale pour créer une exception en Java ?

StackOverflow https://stackoverflow.com/questions/26984

  •  09-06-2019
  •  | 
  •  

Question

J'ai été dans les deux situations :

  • Créer trop d'exceptions personnalisées
  • Utiliser trop de classes d'exception générales

Dans les deux cas, le projet a bien démarré mais est rapidement devenu une surcharge à maintenir (et à refactoriser).

Alors, quelle est la meilleure pratique concernant la création de vos propres classes d’exception ?

Était-ce utile?

La solution

Les spécialistes Java a écrit un article sur Exceptions en Java, et ils y répertorient quelques « meilleures pratiques » pour créer des exceptions, résumées ci-dessous :

  • N'écrivez pas vos propres exceptions (il existe de nombreuses exceptions utiles qui font déjà partie de l'API Java)

  • Écrivez des exceptions utiles (si vous devez écrire vos propres exceptions, assurez-vous qu'elles fournissent des informations utiles sur le problème survenu)

Autres conseils

Ne faites pas ce que les développeurs de mon entreprise ont fait.Quelqu'un a créé une InvalidArguementException [sic] qui est parallèle à java.lang.IllegalArgumentException, et nous l'utilisons maintenant dans (littéralement) des centaines de classes.Les deux indiquent qu'une méthode a reçu un argument illégal ou inapproprié.Tu parles d'un gaspillage...

Joshua Bloch en parle dans Guide efficace du langage de programmation Java [ma bible de premier recours sur les Bonnes Pratiques] Chapitre 8.Des exceptions Article 42 :Favoriser le recours aux exceptions standards.Voici un peu ce qu'il dit,

La réutilisation d’exceptions préexistantes présente plusieurs avantages.Le principal d'entre eux est qu'il rend votre API plus facile à apprendre et à utiliser car il correspond aux conventions établies avec lesquelles les programmeurs sont déjà familiers [c'est moi qui souligne, pas celui de Bloch].En deuxième position, les programmes utilisant votre API sont plus faciles à lire car ils ne sont pas encombrés d'exceptions inconnues.Enfin, moins de classes d’exception signifient une empreinte mémoire plus petite et moins de temps passé à charger les classes.

L’exception la plus couramment réutilisée est IllegalArgumentException.Il s'agit généralement de l'exception à lever lorsque l'appelant transmet un argument dont la valeur est inappropriée.Par exemple, ce serait l'exception à lancer si l'appelant transmettait un nombre négatif dans un paramètre représentant le nombre de fois qu'une action devait être répétée.

Cela dit, tu devrais jamais lancer l'exception elle-même.Java dispose d'un ensemble d'exceptions intégrées bien choisies, diversifiées et bien ciblées qui couvrent la plupart des situations. ET décrivez suffisamment bien l'exception qui s'est produite pour que vous puissiez remédier à la cause.

Soyez amical avec les programmeurs qui devront maintenir votre code à l’avenir.

Ma règle générale est que lorsque le client (l'appelant) peut raisonnablement vouloir faire quelque chose de différent, en fonction du type d'exception levée, les types d'exceptions supplémentaires sont justifiés.Toutefois, le plus souvent, les types d’exceptions supplémentaires ne sont pas nécessaires.Par exemple, si l'appelant écrit du code comme

try {
     doIt();
} catch (ExceptionType1 ex1) {
     // do something useful
} catch (ExceptionType2 ex2) {
     // do the exact same useful thing that was done in the block above
}

alors il est clair que les types d’exceptions supplémentaires ne sont pas nécessaires.Trop souvent, je vois (ou suis obligé d'écrire) du code comme celui-ci parce que le code appelé était trop zélé dans sa création de nouveaux types d'exceptions.

Si je ne trouve pas d'exception dont le nom décrit le type d'erreur qui a été provoqué, je crée la mienne.

C'est ma règle générale.

Fondamentalement, chaque travail mérite sa propre exception.Lorsque vous détectez des exceptions, vous ne distinguez pas les différentes instances, comme vous le feriez normalement avec des objets, vous avez donc besoin de différents sous-types.Utiliser trop d’exceptions personnalisées est un cas que je vois rarement se produire.

Un conseil serait de créer des exceptions si nécessaire, et s'il devient évident qu'un type d'exception est un double d'un autre, refactorisez le code en fusionnant les deux.Bien sûr, il est utile de réfléchir dès le début à la structuration des exceptions.Mais en général, utilisez des exceptions personnalisées pour tous les cas qui n'ont pas de correspondance 1:1 avec les exceptions existantes spécifiques à la situation.

D'autre part, NullPointerExceptionsable IndexOutofBoundsExceptions pourraient en fait souvent être appropriés.Ne les détectez pas, cependant (sauf pour la journalisation), car il s'agit d'une erreur de programmation, ce qui signifie qu'après les avoir lancés, le programme est dans un état indéfini.

Ma propre règle de base :

Je ne lance jamais d'exception, sauf dans les tests unitaires lorsque ce que vous lancez n'est pas pertinent et qu'il n'y a aucune raison d'y consacrer plus de temps.

Je crée mon propre type d'exception personnalisé pour les erreurs survenant dans ma logique métier personnalisée.Ce type d'exception est utilisé autant que possible pour refondre d'autres exceptions, sauf dans les cas où il est logique que le client ait une visibilité sur ce qui s'est réellement produit.

En créant votre propre exception :

  • Toutes les exceptions doivent être un enfant du Classe jetable

  • Si vous souhaitez écrire une exception vérifiée qui est automatiquement appliquée par la règle Handle ou Declare, vous devez étendre la Classe d'exceptions

  • Si vous souhaitez écrire une exception d'exécution, vous devez étendre la classe d'exception d'exécution.

Ne mangez pas d'exceptions, jetez-les https://stackoverflow.com/a/921583/1097600

Évitez de créer votre propre exception.Utilisez ceux ci-dessous qui sont déjà là.

IllegalStateException
UnsupportedOperationException
IllegalArgumentException
NoSuchElementException
NullPointerException

Lancez des exceptions non vérifiées.

Exemple

public void validate(MyObject myObjectInstance) {
    if (!myObjectList.contains(myObjectInstance))
        throw new NoSuchElementException("object not present in list");
}
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top