java.lang.Exception ou roulement de votre propre exception

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

Question

À quel moment voudriez-vous créer votre propre classe d'exception par rapport à l'utilisation de java.lang.Exception? (Tout le temps? Seulement s'il sera utilisé en dehors du paquet? Seulement s'il doit contenir une logique avancée? Etc ...)

Était-ce utile?

La solution

Je pense que vous devez vous poser une question légèrement différente & "Quel avantage la création d'une nouvelle exception procure-t-elle à moi-même ou aux développeurs qui utilisent mon code? &"; En réalité, le seul avantage que cela procure, à vous ou à d’autres personnes, est la capacité de gérer l’exception. Cela semble une réponse évidente mais ce n’est vraiment pas le cas. Vous ne devriez gérer que des exceptions que vous pouvez raisonnablement récupérer. Si l’exception que vous lancez est une erreur vraiment fatale, pourquoi laisser aux développeurs une occasion de la manipuler?

Discussion plus approfondie: Exceptions personnalisées: quand les créer?

Autres conseils

Raison un:

Besoin d'attraper des trucs spécifiques. Si le code appelant doit traiter une condition exceptionnelle spécifique, vous devez différencier votre exception et Java différenciant les exceptions avec différents types. Vous devez donc écrire la vôtre.

Fondamentalement, si quelqu'un doit écrire: 

catch(ExistingException e) {
  if({condition}) {
    { some stuff here}
  }
  else {
    { different stuff here}
  }
}

Vous voulez probablement écrire une extension spécifique; catch La correspondance des exceptions est plus claire que les conditions, IMHO.

N'oubliez pas: votre nouvelle exception peut être une sous-classe de RuntimeException

.

Raison deux:

Consolidation de l'API. Si vous écrivez une interface et que vous avez plusieurs implémentations, il est possible qu'elles appellent différentes API avec tout un tas de différentes exceptions non-RuntimeExceptions: 

interface MyInterface {
  void methodA();
}

class MyImplA {
  void methodA() throws SQLException { ... }
}

class MyImplB {
  void methodA() throws IOException { ... }
}

Voulez-vous vraiment que MyInterface.methodA lève les exceptions SQLException et IOException? Dans ce cas, il peut être judicieux de regrouper les exceptions possibles dans une exception personnalisée. Ce qui peut encore être une exception RuntimeException. Ou même RuntimeException elle-même ...

Je crois que: 

catch (Exception e) {
   ...
}

... est un antipattern qui devrait être évité. Vous voudrez peut-être une capture unique centralisée quelque part dans votre application, afin de consigner une erreur et d’empêcher toute l’application de se terminer, mais leur dispersion éparpillée de gré ou de force est une mauvaise chose.

Pourquoi: 

try {
   if(myShape.isHidden()) {
      throw new Exception();
   }
   // More logic
} catch (Exception e) {
   MyApp.notify("Can't munge a hidden shape");
}

Donc, vous essayez ceci et, en raison d’une erreur de codage, myShape est null. Une exception NullPointerException est émise lorsque le moteur d'exécution tente de déréfender myShape. Ce code signale une forme cachée, alors qu’il devrait signaler un pointeur nul.

Créez votre propre exception ou recherchez une exception spécialisée dans l'API. Ce n’est pas comme si prolonger Exception ou RuntimeException était onéreux.

Lorsque je veux traiter mes exceptions différemment de celles des autres. Si je veux attraper le mien et propager celui de tout le monde, ou si je veux attraper celui d'un autre et propager le mien, ou si je veux attraper les deux mais en les traitant différemment, je définirai une classe séparée pour mes exceptions. Si je veux les traiter tous de la même manière, soit en propageant les deux, soit en les attrapant (et en faisant la même chose dans les deux cas avec les exceptions interceptées), je vais utiliser la classe standard.

S'il existe une exception existante avec le langage d'exécution ou les bibliothèques, utilisez-la sinon créez la vôtre, documentez-la et cela fonctionnera dans 99% des cas.

Le logiciel saisit la signification.

Il n’existe pratiquement aucune raison de lever une exception existante: la JVM le fait déjà pour vous. Votre version de leur exception n'est pas vraiment précise et jette & "Exception &"; n'a pas de sens non plus.

Vous pourriez avoir un DataFormatException en raison d'un algorithme d'analyse que vous avez écrit. Ceci cependant est rare.

Lorsque votre programme rencontre une situation exceptionnelle, elle est presque toujours unique. Pourquoi forcer votre situation exceptionnelle dans une exception existante? Si c'est unique dans votre programme, alors ... eh bien, c'est unique. Nommez-le ainsi.

Toutefois, ne fournissez pas une classe d'exception unique pour chaque message unique. Une exception class peut comporter de nombreux variantes de message et informations complémentaires.

La règle empirique Python, traduite en Java, consiste à définir toute exception unique au niveau du package. [En Python, ils suggèrent des exceptions au & Quot; module & Quot; niveau, quelque chose qui ne se traduit pas précisément en Java.]

Commencez toujours par utiliser les classes d'exception communes, puis modifiez-le lorsqu'un besoin apparaît de le gérer spécialement.

  1. Lorsque vous créez une méthode pour la première fois, laissez simplement les exceptions passer.

  2. Si des exceptions doivent être gérées, celles-ci peuvent être simplement définies dans des projections ou intégrées à une exception d'exécution ou à une exception associée à une exclusion. Je préfère les exceptions d'exécution dans de nombreux cas. Il faut éviter de définir la définition des jets tant que l’API n’a pas besoin de le faire.

  3. Plus tard, lorsqu'un besoin apparaît de traiter de manière spécifique une exception chez un appelant, revenez et créez une nouvelle exception pour elle.

Il faut éviter de faire un travail supplémentaire avant de savoir ce dont on a besoin.

Je ne peux pas imaginer spécifiquement lancer une exception java.lang.Exception si un objet / une classe / une méthode rencontrait un problème. C'est trop générique - si vous n'allez pas créer votre propre classe Exception, il me semble qu'il devrait au moins y avoir un type d'Exception plus spécifique dans l'API.

J'utiliserais les exceptions de l'API Java lorsque l'exception concerne l'API. Mais si une situation exceptionnelle se produit et est propre à ma propre API, je vais créer une exception pour celle-ci. Par exemple, si j’ai un objet Range avec deux propriétés min et max et l’invariant min & Lt; = max, je vais créer une exception InvalidRangeException.

Lorsque j'écris du code, cela aide, car je sais si l'exception provient d'une violation de l'une de mes propres conditions ou de quelque chose de l'API Java.

Dans la plupart des cas, il n’a pas de sens de créer votre propre classe d’exception.

Les programmeurs débutants ont tendance à créer leur propre classe d’exception pour pouvoir utiliser un nom plus représentatif du type d’erreur. Vous trouverez donc des classes telles que FTPInitializationException, DAOFactoryException, etc. même si ces exceptions ne sont pas gérées différemment des exceptions standard. Ceci est clairement un modèle anti qui devrait être évité.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top