Parfois, il vous suffit d'attraper jetable, par exemple. Lors de l'écriture d'une file d'attente de répartition qui envoie des éléments génériques et doit récupérer de toutes les erreurs (lesdits journaux du répartiteur toutes les exceptions pris, mais en silence, puis l'exécution est poursuivie sur d'autres éléments).
Une meilleure pratique que je puisse penser, c'est toujours repenser l'exception si elle est interrompueException, car cela signifie que cela signifie que quelqu'un interrompit mon fil et veut le tuer.
Une autre suggestion (qui est venue d'un commentaire, pas une réponse) est de toujours réthrow Autres meilleures pratiques?
4 Réponses :
Probablement le plus important est, sauf si c'est ce que vous avez l'intention em>. Parfois, les gens avalent des exceptions vérifiées car elles ne savent pas quoi faire avec eux ou ne veulent pas (ni ne pas) polluer leur interface avec des clauses de «exception». P> si vous ne le faites pas Sachez quoi faire avec cela, faites ceci: P> FileInputStream in = null;
try {
in = new FileInputStream(new File("..."));;
// do stuff
} catch (IOException e) {
// deal with it appropriately
} finally {
if (in != null) try { in.close(); } catch (IOException e) { /* swallow this one */ }
}
+1 sur la non-avalée d'une exception vérifiée - même dans votre «premier passage». Trop souvent, ces choses sont négligées et finalement soumises au contrôle de la source. En cas de doute, imprimez au moins la trace de la pile.
Si vous ne pouvez pas le gérer et que vous ne pouvez pas retirez-le, d'au moins imprimer cette trace de pile! Une trace de pile dans le journal est une aide précieuse pour diagnostiquer le problème.
L'horreur des exceptions vérifiées ... Catch IoException uniquement pour l'envelopper dans une exception non vérifiée et ne rien faire avec tout cela? Bien sûr, c'est ce que vous devez faire à Java, à moins que vous ne sachiez réellement pourquoi vous obtenez l'exception.
-1 La question concerne attraper des lautres et des meilleures techniques, il ne s'agit pas d'avaler des exceptions vérifiées.
Quand Java a-t-il ajouté Catch (lancé)? Ou a-t-il toujours été là et je ne le savais pas?
dépend de ce que vous travaillez.
Si vous développez une API à utiliser par quelqu'un d'autre, il est préférable de ré-jeter l'exception ou de la envelopper dans une exception personnalisée de la vôtre et de lancer.
alors que si vous développez une application SONDUSER, vous devez gérer cette exception et faire le nécessaire.
Si vous écrivez une file d'attente de répartiteur, alors au moment où l'exception vous revient, il ne sert à rien de faire quoi que ce soit d'autre que de l'exploiter. La file d'attente d'événement Swing a essentiellement ce type de comportement.
Alternativement, vous pouvez fournir un crochet pour un "gestionnaire d'exceptions non capturies" similaire à En ce qui concerne l'interromptionException: la seule chose qui se soucie de celle-ci est votre boucle d'expédition, ce qui devrait vérifier un état externe pour voir s'il doit arrêter le traitement.
Pourquoi vérifie-t-on mieux un état externe que l'utilisation d'une exception interrompue comme mécanisme de signalisation?
Parce que l'interromptionException indique simplement que quelqu'un appelé interruption () sur le thread. Il pourrait y avoir de multiples raisons pour cela, non seulement de mettre fin à l'action actuelle. Et si vous souhaitez utiliser Interruption () pour terminer le répartiteur, vous ne voulez certainement pas le jeter; Revenez simplement de la course () - à moins que, bien sûr, votre répartiteur n'est pas la seule chose que le fil va, mais même là, vous ne voulez certainement pas aveugner.
Qu'en est-il de l'OutofMemoryError (ou peut-être de sa super classe virtuelleMachineError)? Je ne peux pas imaginer qu'il y a beaucoup que vous pouvez faire après quelque chose de sérieux.
Si le fil qui a affecté beaucoup d'objets arrive à attraper l'OutOfMemoryError à un point où les ordures allouées deviennent à collectionner, le VM peut récupérer. Si les objets sont toujours référencés, alors oui, vous ne pouvez pas faire beaucoup, sauf quitter ou libérer certains objets.
Catch VirtualMachineError est délicat car votre programme est alors dans un état non défini: Stackoverflow.com/questions/8728866/...
FilkDeath devrait également être retiré, mais cela ne devrait pas être lancé en premier lieu.Pourquoi un commentaire, c'est juste le type de réponse que je voulais?