Há alguns anos, não consigo obter uma resposta decente para a seguinte pergunta: por que alguns desenvolvedores são tão contra as exceções verificadas? Tive várias conversas, li coisas em blogs, li o que Bruce Eckel tinha a dizer (a primeira pessoa que vi falar contra eles).

Atualmente, estou escrevendo um novo código e prestando muita atenção em como lido com exceções. Estou tentando ver o ponto de vista da multidão "não gostamos de exceções verificadas" e ainda não consigo vê-lo.

Toda conversa que tenho termina com a mesma pergunta sem resposta ... deixe-me configurá-la:

Em geral (de como o Java foi projetado),

Error é para coisas que nunca devem ser capturadas (a VM tem alergia a amendoim e alguém deixou cair um pote de amendoim)RuntimeException é para coisas que o programador fez de errado (o programador saiu do final de uma matriException (exceto RuntimeException) é para coisas que estão fora do controle do programador (o disco é preenchido durante a gravação no sistema de arquivos, o limite de manipulação de arquivos para o processo foi atingido e você não pode abrir mais arquivos) Throwable é simplesmente o pai de todos os tipos de exceçã

Um argumento comum que ouvi é que, se uma exceção acontecer, tudo o que o desenvolvedor fará será sair do program

utro argumento comum que ouvi é que as exceções verificadas dificultam a refatoração do códig

Para o argumento "tudo o que vou fazer é sair", digo que mesmo se você estiver saindo, precisará exibir uma mensagem de erro razoável. Se você está apenas tentando manipular erros, seus usuários não ficarão muito felizes quando o programa terminar sem uma indicação clara do porquê.

Para a multidão "dificulta a refatoração", isso indica que o nível adequado de abstração não foi escolhido. Em vez de declarar que um método lança uma IOException, a IOException deve ser transformada em uma exceção mais adequada ao que está acontecendo.

Eu não tenho um problema ao agrupar Main com catch (Exception) (ou, em alguns casos, catch (Throwable) para garantir que o programa possa sair normalmente - mas eu sempre pego as exceções específicas de que preciso). , no mínimo, exiba uma mensagem de erro apropriad

A pergunta que as pessoas nunca respondem é a seguinte:

Se você jogar as subclasses RuntimeException em vez das subclasses Exception, então como você sabe o que deve pega

Se a resposta for pegar Exceção, você também estará lidando com erros de programador da mesma maneira que as exceções do sistema. Isso parece errado para mi

Se você pegar Throwable, estará tratando exceções do sistema e erros de VM (e similares) da mesma maneira. Isso parece errado para mi

Se a resposta for que você captura apenas as exceções que você sabe que são lançadas, então como você sabe quais são lançadas? O que acontece quando o programador X lança uma nova exceção e esquece de capturá-la? Isso me parece muito perigoso.

Eu diria que um programa que exibe um rastreamento de pilha está errado. As pessoas que não gostam de exceções verificadas não se sentem assim?

Então, se você não gosta de exceções verificadas, pode explicar por que não e responder à pergunta que não foi respondida, por favo

Edit: Eu não estou procurando conselhos sobre quando usar qualquer modelo, o que eu estou procurando éporqus pessoas @ estendem-se a partir de RuntimeException porque não gostam de estender a partir de Exception e / ou porque capturam uma exceção e, em seguida, reproduzem novamente uma RuntimeException em vez de adicionar lançamentos ao método. Quero entender a motivação para não gostar de exceções verificadas.