web-dev-qa-db-fra.com

La plupart des exceptions Java cochées et non cochées?

Pour autant que je sache, il n’existe aucun moyen de savoir quelles exceptions une méthode génère sans consulter les documents de l’API un par un. 

Comme ce n'est pas une option, j'aimerais inverser la recherche et vous demander quelles sont les exceptions les plus courantes et les exceptions RuntimeExceptions que vous avez rencontrées lorsque vous traitez avec:

  • Moulage
  • Tableaux
  • Vecteur, ArrayList, HashMap, etc.
  • IO (classe de fichier, flux, filtres, ...)
  • Sérialisation des objets
  • Fils (wait (), sleep (), etc.)
  • ou tout ce qui est considéré comme "Java de base"

Je me rends compte que cela peut être subjectif et ennuyeux, mais c’est pour un test de classe et je ne sais vraiment pas mieux.

javaexception
30
Brian Johnson

Supposons que les éléments ci-dessous correspondent à Java.lang, sauf indication contraire de ma part:

  • Casting: ClassCastException
  • Arrays: ArrayIndexOutOfBoundsException, NullPointerException
  • Collections: NullPointerException, ClassCastException (si vous n'utilisez pas l'autoboxing et que vous le bousillez)
  • IO: exception Java.io.IOException, exception Java.io.FileNotFoundException, Java.io.EOFException
  • Sérialisation: Java.io.ObjectStreamException (ET SES SOUS-CLASSES, que je suis trop paresseux pour énumérer)
  • Threads: InterruptedException, SecurityException, IllegalThreadStateException
  • Potentiellement commun à toutes les situations: NullPointerException, IllegalArgumentException

Vous feriez bien de consulter les pages de résumé des packages du site Java. En voici un: http://Java.Sun.com/j2se/1.4.2/docs/api/Java/io/package-summary.html

36
Platinum Azure

Liste des exceptions non vérifiées
ArrayIndexOutOfBoundsException
ClassCastException
Exception d'argument illégal
IllegalStateException
NullPointerException
NumberFormatException
AssertionError
ExceptionInInitializerError
StackOverflowError
NoClassDefFoundError 

Liste des exceptions vérifiées
Exception
IOException
FileNotFoundException
ParseException
ClassNotFoundException
CloneNotSupportedException
InstantiationException
InterruptedException
NoSuchMethodException
NoSuchFieldException 

26
Praveen Kishor

NullPointerException

22
Gandalf

Java.lang:  

  1. ArithmeticException
  2. ArrayIndexOutOfBoundsException
  3. ClassCastException
  4. ClassNotFoundException
  5. CloneNotSupportedException
  6. IllegalArgumentExcepion
  7. IllegalMonitorStateException
  8. IllegalThreadStateException
  9. IndexOutOfBoundsException
  10. InterruptedException
  11. NullPointerException
  12. NumberFormatedException

Java.util:  

  1. ConcurrentModificationException

Java.io:

  1. EOFException
  2. FileNotFoundException
  3. IOException
  4. NotSerializableException
7
ADITYA VALLURU

Comme le dit le projet de loi K. Les exceptions vérifiées sont faciles. Si votre éditeur de programme/IDE ne vous donne pas un moyen rapide de voir les méthodes javadocs ou les signatures, vous devez le jeter. Sérieusement.

Les exceptions non contrôlées sont un autre type de poisson. Mais je pense que la meilleure stratégie avec des exceptions non contrôlées est de ne pas essayer de les attraper. Au lieu de cela, vous écrivez votre code pour qu’il évite de le lancer en premier lieu. Par exemple;

// ... not sure if 'obj' is null
if (obj != null) {
    obj.someMethod();
}
// ... not sure if 'obj' has the right type
if (obj instanceof Foo) {
    Foo foo = (Foo) obj;
}
// ... not sure if 'i' is in range
if (i >= 0 && i < array.length) {
    .... = array[i];
}

Voici pourquoi je recommande ceci:

  • Un test de garde est des ordres de grandeur plus efficace que de lancer et de capturer une exception.
  • Un test de garde est plus lisible ... moins de lignes de code.
  • Si vous attrapez une exception non contrôlée, vous ne pouvez jamais être sûr que cela s'est produit pour les raisons qui, selon vous, l'ont été. par exemple:
 // obj pourrait être null ...
 essayez {
 obj.doquelquechose (); 
 } catch (NullPointerException ex) {
 System.err.println ("obj était null"); // FAUX!!!
 // le NPE aurait pu se produire dans doSomething () 
 }
  • Si une exception non contrôlée est provoquée par un bogue, vous NE voulez PAS de pile et, en fonction de l'application, vous ne pouvez PAS vouloir récupérer.

Évidemment, vous n'incluez que ces vérifications de "garde" où votre compréhension du code vous indique qu'elles sont nécessaires! Ainsi, par exemple, si vous savez que "obj" doit être non nul et que "i" doit être à portée, il est judicieux de laisser les chèques. Si vous omettez un test de trop, vous obtiendrez une exception ... mais c'est bien, vous pouvez ensuite utiliser le stacktrace pour comprendre pourquoi votre compréhension du code était erronée et peut-être corriger le bogue sous-jacent.

3
Stephen C

J'aimerais contribuer à une liste qui regroupe par situation, ce qui est probablement plus significatif que de regrouper des packages ou des domaines de programmation.

Exceptions inattendues

Ce sont des exceptions qui, idéalement, ne devraient jamais être intégrées à la production. Vous devriez les réparer au lieu de les attraper et stfu.

lorsque vous testez du code nouvellement écrit (et parfois vu de manière inattendue par les utilisateurs)

Ils ne devraient jamais se reproduire une fois que vous les voyez.

  • AssertionError
    • félicitations, vous écrivez un bon code
    • vous devriez être heureux que vous ayez fait cette erreur, car moins (erreurs) est plus (bugs)
    • J'espère que vous ne finirez pas par découvrir que votre code est correct et que vous avez accidentellement inversé votre assertion
  • NullPointerException
    • où sont vos @NotNulls?
    • avez-vous vérifié avant d'utiliser la valeur de retour de Map.get()?
  • ArrayIndexOutOfBoundsException
    • vérifiez-vous avant d'utiliser List.get()?
    • J'espère que vous savez bien que Java n'est pas du JavaScript, les tableaux sont de taille fixe et vous ne pouvez pas simplement array[array.length] = newElement
  • ClassCastException
    • trop de génériques nuit aux cellules de votre cerveau; envisager de déménager à Golang!
  • Exception d'argument illégal
    • cela pourrait parfois signifier "lisez le poissoning docs "

Et moins susceptible de voir,

  • IllegalMonitorStateException
    • oui, avoir synchronized est nul, mais c'est comme ça dans la plupart des langues
  • CloneNotSupportedException
    • hé, n'utilisez pas clone (). Les constructeurs de copie ne sont-ils pas cool?

Et puis vous obtenez plus de NullPointerException.

Et ensuite ... Toujours NullPointerException? Cette annotation @NotNull est une foutaise!

lorsque vous testez le code nouvellement écrit pour la centième fois

Les exceptions qui se produisent en raison de conditions de course ou de probabilité rare. Vous devriez acheter une loterie si vous les voyez les 10 premières fois que vous exécutez votre code.

  • ConcurrentModificationException
    • ? votre synchronized est où
  • IllegalStateException
  • StackOverflowError (not Exception)
    • avez-vous essayé la récursion de la queue?

pendant la compilation, le déploiement, etc.

Ils se produisent généralement lorsque vous avez gâché les dépendances, utilisé de mauvaises versions de bibliothèques, etc.

  • LinkageError
  • NoClassDefFoundError
  • Java.lang.XxxNotFoundException, Java.lang.NoSuchXxxException (classes, méthodes, etc.)
    • pas de reflets s'il vous plaît

quand tu es trop paresseux

et quand vous utilisez @lombok.SneakyThrows ou équivalent

  • RuntimeException
  • ? étend RuntimeException

Exceptions attendues

S'ils ne sont pas attrapés, cela signifie probablement que vous êtes également trop paresseux. Vous ne pouvez pas les empêcher de lancer; il suffit de les attraper.

haute probabilité

Il est fort probable que ces exceptions se produisent et doivent toujours être traitées de manière spécifique (c’est-à-dire que vous devriez les gérer au lieu de simplement afficher l’erreur).

  • NumberFormatException
    • Je ne comprends jamais pourquoi cette exception étend RuntimeException.

probabilité moyenne

Ces exceptions sont parfois dues à une entrée utilisateur non valide (mais vous devez les valider, je les classe donc comme des "exceptions inattendues") et parfois à cause de contraintes système qui pourraient ne pas être reproductibles lors de tests (sans contrainte).

  • IOException et autre exception Java.io.XxxException
  • Exception de sécurité
  • StackOverflowException
    • malheureusement, aller à StackOverflow ne corrigera probablement pas vos exceptions StackOverflowEx, car vous obtiendrez plus de piles dépassées si vous cherchez quelque chose à Ctrl-C et Ctrl-V.
  • StackUnderflowException
    • non, StackOverflow ne va toujours pas aider beaucoup
  • OutOfMemoryError
    • J'espère que ce n'est pas une fuite de mémoire
2
SOFe

Les exceptions cochées sont faciles, votre éditeur doit afficher les javadocs lorsque vous survolez/complétez le nom de la méthode.

Les erreurs non vérifiées sont généralement des erreurs réelles et ne sont même pas le plus souvent dans les javadocs. Je suppose que la plus courante pourrait être IllegalArgumentException, toute méthode ayant une combinaison de paramètres non valide qui devrait être renvoyée.

1
Bill K

Que diriez-vous de chercher des sous-classes de Java.lang.exception, par exemple ici

Personnellement, j'utilise 2 exceptions vérifiées de ma propre TransientException dans les cas où une nouvelle tentative pourrait fonctionner. Et InvalidRequestException pour les erreurs de validation.

1
djna

NumberFormatException

1
firstthumb

  • Casting - ClassCastException

  • Tableaux - ArrayIndexOutOfBoundsException

  • Vector, ArrayList, HashMap, etc. - Je vois rarement des exceptions lorsque je travaille avec des collections Java, mais très occasionnellement, ConcurrentModificationException

  • IO (classe de fichier, flux, filtres,…) - FileNotFoundException

  • Sérialisation d'objet - ClassNotFoundException

  • Threads (wait (), sleep (), etc.) - D'après mon expérience, les problèmes de threads se manifestent généralement de manière aléatoire, sans exception spécifique. Le fait de devoir faire face à InterruptedException prend beaucoup de temps, bien que je n’aie pas vu l’exception levée.

  • ou tout ce qui est considéré comme un "Java de base" - l'exception de loin la plus commune selon mon expérience est NullPointerException.

0
Warren Dew