Quand à attraper java.lang.D'erreur?

Question

Dans quelles situations doit-on attraper java.lang.Erreur sur une application?

Answer 1

Généralement, jamais. Cependant, parfois, vous avez besoin pour attraper les Erreurs spécifiques.

Si vous êtes à la rédaction de cadre-ish (code de chargement de la 3e partie des classes), il pourrait être sage de catch LinkageErrors (pas de classe def trouvé, insatisfait de lien, incompatible changement de classe). J'ai aussi vu certains stupide de la 3e partie du code de jeter sublcasses d'Erreurs, de sorte que vous aurez à gérer ces deux.

En passant, je ne suis pas sûr qu'il n'est pas possible de récupérer d'un dépassement de mémoire.

Answer 2

Jamais. Vous ne pouvez jamais être sûr que l'application est capable d'exécuter la ligne de code suivante. Si vous obtenez une OutOfMemoryError, vous n'avez aucune garantie que vous serez en mesure de quoi que ce soit. Catch RuntimeException et vérifié Exceptions, mais jamais d'Erreurs.

http://pmd.sourceforge.net/rules/strictexception.html

Answer 3

Généralement, vous ne devez l'attraper, jamais et l'écrire dans un journal ou l'afficher à l'utilisateur. Je travaille dans le soutien d'une je vois tous les jours que les programmeurs ne sais pas ce qui va dans votre programme.

Si vous avez fil de démon, alors vous devez éviter qu'il dénoncé. Dans les autres cas, votre application fonctionne correctement.

Vous devez attraper seulement sur le dessus.

Si vous voyez la liste des erreurs, alors vous voyez que la plupart peuvent être traités. Par exemple, un ZipError se produire sur la lecture de la corruption de fichiers zip.

La plupart des erreurs sont OutOfMemoryError et NoClassDefFoundError. Les deux sont dans la plupart des cas d'exécution de problèmes.

par exemple:

int length = Integer.parseInt(xyz);
byte[] buffer = new byte[length];

peut produire un OutOfMemoryError mais c'est un problème d'exécution et non la cause de la fin de votre programme.

Le NoClassDefFoundError se produisent surtout si une bibliothèque n'est pas présent ou si vous travaillez avec une autre version de Java. Si c'est une partie facultative de votre programme, alors vous ne devriez pas mettre fin à votre programme.

Je peux écrire beaucoup plus d'échantillons pourquoi c'est un godd idée d'attraper Throwable sur le dessus et produire une erreur utile de sortie.

Answer 4

En environnement multithread, vous le plus souvent envie de l'attraper! Quand vous le prenez, vous connecter, et de résilier l'ensemble de l'application! Si vous ne le faites pas, certains thread qui pourrait faire une partie cruciale serait mort, et le reste de l'application va se dire que tout est normal. En dehors de cela, de nombreuses situations indésirables peuvent se produire. Un seul petit problème, c'est que vous ne seriez pas en mesure de trouver facilement l'origine du problème, si d'autres threads commencer à jeter quelques exceptions à cause d'un fil ne fonctionne pas.

Par exemple, habituellement boucle doit être:

try {
   while (shouldRun()) {
       doSomething();
   }
}
catch (Throwable t) {
   log(t);
   stop();
   System.exit(1);
}

Même, dans certains cas, vous pouvez traiter les différentes Erreurs différemment, par exemple, sur OutOfMemoryError vous seriez en mesure de fermer l'application régulièrement (même peut-être libérer de la mémoire, et de continuer), sur certains autres, il n'y a pas beaucoup que vous pouvez faire.

Answer 5

Très rarement.

Je dirais qu'au niveau supérieur d'un thread pour TENTER de délivrer un message à la raison pour un thread en train de mourir.

Si vous êtes dans un cadre qui fait ce genre de chose pour vous, laissez faire le cadre.