La doc de l'API indique ne jamais attraper Throwable sous-classe Erreur qui indique un comportement anormal. Cela implique-t-il que la séparation entre Error et Exception consiste à dire aux programmeurs quelle sous-classe doit être détectée et laquelle ne devrait pas l'être? Ou y a-t-il plus?Quelle sous-classe de Throwable devrait être attrapée et laquelle ne devrait pas l'être?
En général, Error est quelque chose de grave (souvent dans la plate-forme elle-même) que vous ne pouviez pas gérer. Les seules fois où je me suis soucié d'attraper Error est de log il, après quoi je relancer.
Ceci est extrêmement important car il est facile de laisser des erreurs (et les exceptions d'exécution) se propagent jusqu'à la pile d'appels de telle sorte qu'ils ne sont jamais enregistrés (par exemple à l'aide executorService.submit(Runnable) sans écouter le retour Future)
Error s sont généralement des choses comme:
Je dirait alors que RuntimeException s sont généralement (mais pas toujours) indiquant erreurs de programmation:
Je recommanderais d'habitude échouer-rapide sur ceux-ci aussi mais c'est une zone grise; peut-être que vous ne vérifiez pas l'entrée de l'utilisateur avant de la transmettre au serveur, ce qui ne vaut pas la peine d'écraser votre application!
Vérifié Exception s (c'est-à-dire non-runtime) doit être utilisé pour les éléments que vous pourriez raisonnablement espérer voir se produire et raisonnablement (ou éventuellement) gérer dans votre code. Personnellement, j'aime les exceptions vérifiées, mais celles-ci sont lourdes à cause de la verbosité/répétition impliquée dans le traitement de types d'exceptions distincts de la même manière (c'est-à-dire dans plusieurs blocs catch identiques).Des langages tels que Scala ont une meilleure syntaxe de capture, mais ils ont également supprimé le concept des exceptions cochées!
Oui, je pense que votre analyse est correcte ici - vous n'êtes pas censé attraper Error s parce qu'ils représentent des erreurs d'exécution qui ne peuvent pas être récupérées, comme OutOfMemoryError. La seule raison pour attraper Throwable est si vous exécutez le code tiers externe qui n'est pas nécessaire pour le bon fonctionnement de votre programme - si vous ne faites pas confiance à ce code, attrapez tout et si vous obtenez des choses que vous ne m'attendais pas (Throwable) puis désactiver ce code et le signaler.
Aussi, il pourrait être une bonne idée de faire la distinction entre Exception et RuntimeException.
Aimé l'idée de code de tiers. Je vous remercie –