Qual subclasse de arremesso deve ser capturada e qual não deveria?

Question

Doc da API diz nunca pegar Jogável subclasse Erro que significa comportamento anormal. Isso implica que a segregação entre erro e exceção é dizer aos programadores que a subclasse deve ser capturada e qual não deveria? Ou há mais nisso?

Answer 1

No geral, Error é algo seriamente errado (geralmente dentro da própria plataforma) que você não poderia lidar com a concepção. As únicas vezes que eu já me importei em pegar Error é para Log It, depois do qual eu então re-arrote.

Isso é de vital importância, pois é fácil deixar erros (e exceções de tempo de execução) propagam a pilha de chamadas de tal maneira que eles nunca são registrados (por exemplo, usando executorService.submit(Runnable) sem ouvir o devolvido Future)

ErrorS geralmente são coisas como:

• fora da memória
• Erro de método abstrato (por exemplo, em execução contra diferentes versão das bibliotecas para aqueles construídos contra)
• Afirações (ou seja, definido pelo programador invariantes, ou coisas que nunca devem acontecer - lol!)

Eu então diria isso RuntimeExceptions são geralmente (embora nem sempre) indicativos de programação erros:

• não checando para nulo ou passar nulo
• passando em argumentos inválidos ou permitindo estado inválido
• Modificando uma coleção como você está iterando sobre ela

Eu normalmente recomendaria falhar em isso também, mas esta é uma área cinzenta; Talvez você não verifique a entrada do usuário antes de passá -lo para o servidor -vale a pena travar seu aplicativo!

Verificado ExceptionS (ou seja, não-ruptura) deve ser usado para coisas que você pode esperar razoavelmente acontecer e razoavelmente (ou concebivelmente) manipular seu código. Pessoalmente, eu gosto de exceções verificadas, mas elas são tornadas pesadas por causa da verbosidade/repetição envolvidas no manuseio de tipos de exceção distintos da mesma maneira (ou seja, em vários blocos de captura idênticos). Idiomas como scala têm uma sintaxe de captura muito melhor, mas depois removeram o conceito de verificado exceções também!

Answer 2

Sim, acho que sua análise está correta aqui - você não deve pegar Errors porque representam erros de tempo de execução que não podem ser recuperados, como OutOfMemoryError.

A única razão para pegar Throwable é se você estiver executando código externo de terceiros que não é necessário para a operação correta do seu programa - se você não confia nesse código, pegue tudo e se você conseguir coisas que não esperava (Throwable) Desative esse código e relate -o.

Também pode ser uma boa ideia distinguir entre Exception e RuntimeException.