web-dev-qa-db-fra.com

Quelles sont les exceptions d'exécution les plus couramment utilisées en Java?

En tant que programmeur Java qui souhaite perfectionner ses compétences en programmation, je rencontre souvent des situations où je dois créer une exception d'exécution. Je sais que c'est une bonne pratique si on l'utilise à bon escient.

Personnellement, NullPointerException et IllegalStateException sont les plus couramment utilisés dans les logiciels que j'ai créés. Et vous?

Quelles exceptions d'exécution utilisez-vous souvent? Dans quelles situations les utilisez-vous?

javaexceptionruntime
45
Winston Chen

Je ne lance jamais NullPointerException. Pour moi, c'est celui qui apparaît naturellement dans le code en cas de problème et qui nécessite qu'un développeur regarde ce qui se passe. Ensuite, il corrige la cause et cela ne se reproduit plus.

J'utilise IllegalStateException pour signaler qu'un objet est mal configuré ou que les appels sont dans un ordre incorrect. Cependant, nous savons tous que dans l'idéal, un objet devrait s'assurer qu'il ne peut pas être dans un mauvais état et que vous ne pouvez pas l'appeler dans un ordre incorrect (créer un générateur et un objet résultant ...).

J'utilise beaucoup de IllegalArgumentException lorsqu'une méthode détecte que ses paramètres sont incorrects. C'est la responsabilité de toute méthode publique, d'arrêter le traitement (pour éviter les erreurs indirectes plus difficiles à comprendre). De plus, quelques if au début d'une méthode servent à la documentation (documentation qui ne s'écarte jamais du code car c'est le code :-)).

     public void myMethod(String message, Long id) {
       if (message == null) {
          throw new IllegalArgumentException("myMethod's message can't be null");
          // The message doesn't log the argument because we know its value, it is null.
       }
       if (id == null) {
          throw new IllegalArgumentException("myMethod's id can't be null");
          // This case is separated from the previous one for two reasons :
          // 1. to output a precise message
          // 2. to document clearly in the code the requirements
       }
       if (message.length()<12) {
          throw new IllegalArgumentException("myMethod's message is too small, was '" + message + "'");
          // here, we need to output the message itself, 
          // because it is a useful debug information.
       }
     }

J'utilise également Exceptions spécifiques à l'exécution pour signaler des conditions exceptionnelles de niveau supérieur.

Par exemple, si un module de mon application ne pouvait pas démarrer, je pourrais avoir une ModuleNotOperationalException levée (idéalement par un code générique comme un intercepteur, sinon par un code spécifique) lorsqu'un autre module l'appelle. Après cette décision architecturale, chaque module doit faire face à cette exception sur les opérations qui appellent d'autres modules ...

68
KLE

J'ai toujours considéré que les exceptions d'exécution devraient représenter des erreurs de programmation (par exemple null référence transmise lorsqu'elle n'est pas attendue, index de tableau hors limites, etc.) tandis que les exceptions vérifiées devraient représenter des conditions exceptionnelles dans l'environnement qui ne peuvent pas être " codé "(par exemple IOException, SQLException).

Une violation de ceci est que parfois vous devrez encapsuler ce qui devrait être une exception vérifiée dans une RuntimeException, afin de satisfaire la définition d'une interface. À titre d'exemple, vous pourriez avoir une implémentation élégante de Java.util.List qui gère une liste distribuée entre plusieurs machines. De toute évidence, cela générerait des exceptions vérifiées (probablement une sous-classe de IOException) si elle était définie seule, mais les avantages de la mise en œuvre de cette classe List est que les clients peuvent l'utiliser de manière presque transparente, partout où ils utilisent une autre liste.

Cela peut conduire à ce que Joel appelle un abstraction qui fuit , cependant, il est donc important que votre documentation soit claire sur les exceptions qui peuvent être levées et ce qu'elles signifient! Dans ce cas, je trouve qu'une sous-classe personnalisée de RuntimeException est généralement plus claire pour communiquer la cause racine plutôt que d'essayer de la transformer en une classe d'exception d'exécution existante.

12
Andrzej Doyle

Selon Joshua Bloch in Java efficace ,

Les exceptions les plus fréquemment réutilisées:

  1. Exception d'argument illégal
  2. IllegalStateException
  3. NullPointerException
  4. IndexOutOfBoundsException
  5. ConcurrentModificationException
  6. UnsupportedOperationException
3
vinS

J'utilise IllegalArgumentException assez souvent. La plupart du temps, j'essaierai de retourner la valeur par défaut dès qu'elle est logique mais parfois ce ne l'était pas, et donc j'utilise celle-ci.

Un autre que j'utilise est ArrayIndexOutOfBoundsException.

3
NawaMan

UnknownException, très utile: P

j'aime aussi org.Apache.commons.lang.NotImplementedException

3
IAdapter

Surtout, je ne lance pas d'exception d'exécution. Plutôt qu'après avoir vérifié des conditions spécifiques, lancez des exceptions définies par l'utilisateur. Mais les quelques que j'ai utilisés sont - IllegalAccessException, ArithmeticException, NumberFormatException et SecurityException.

2
Shruti Rawat