Quando escolher exceções marcadas e não verificadas

https://stackoverflow.com/questions/27578

09-06-2019
|

Pergunta

Em Java (ou qualquer outra linguagem com exceções verificadas), ao criar sua própria classe de exceção, como você decide se ela deve ser marcada ou desmarcada?

Meu instinto é dizer que uma exceção verificada seria necessária nos casos em que o chamador pudesse se recuperar de alguma forma produtiva, enquanto uma exceção não verificada seria mais para casos irrecuperáveis, mas eu estaria interessado nos pensamentos dos outros.

Solução

Exceções verificadas são ótimas, desde que você entenda quando elas devem ser usadas.A API principal do Java não segue essas regras para SQLException (e às vezes para IOException), e é por isso que elas são tão terríveis.

Exceções verificadas deve ser usado para previsível, mas inevitável erros que são razoável recuperar de.

Exceções não verificadas deve ser usado para todo o resto.

Vou explicar isso para você, porque a maioria das pessoas não entende o que isso significa.

Previsível, mas inevitável:O chamador fez tudo ao seu alcance para validar os parâmetros de entrada, mas alguma condição fora de seu controle causou falha na operação.Por exemplo, você tenta ler um arquivo, mas alguém o exclui entre o momento em que você verifica se ele existe e o momento em que a operação de leitura começa.Ao declarar uma exceção verificada, você está dizendo ao chamador para antecipar essa falha.
Razoável para recuperar de:Não faz sentido dizer aos chamadores para anteciparem exceções das quais não poderão se recuperar.Se um usuário tentar ler um arquivo inexistente, o chamador poderá solicitar um novo nome de arquivo.Por outro lado, se o método falhar devido a um bug de programação (argumentos de método inválidos ou implementação de método com erros), não há nada que o aplicativo possa fazer para corrigir o problema no meio da execução.O melhor que pode fazer é registrar o problema e esperar que o desenvolvedor o corrija posteriormente.

A menos que a exceção que você está lançando atenda todos das condições acima, ele deve usar uma exceção não verificada.

Reavalie em todos os níveis:Às vezes, o método que captura a exceção verificada não é o lugar certo para tratar o erro.Nesse caso, considere o que é razoável para seus próprios chamadores.Se a exceção for previsível, inevitável e razoável para a recuperação deles, você mesmo deverá lançar uma exceção verificada.Caso contrário, você deve agrupar a exceção em uma exceção não verificada.Se você seguir esta regra, você converterá exceções verificadas em exceções não verificadas e vice-versa, dependendo da camada em que você está.

Para exceções verificadas e não verificadas, use o nível de abstração correto.Por exemplo, um repositório de código com duas implementações diferentes (banco de dados e sistema de arquivos) deve evitar expor detalhes específicos da implementação lançando SQLException ou IOException.Em vez disso, deve envolver a exceção em uma abstração que abranja todas as implementações (por exemplo, RepositoryException).

Outras dicas

De Um aprendiz de Java:

Quando ocorre uma exceção, você deve pegar e lidar com a exceção, ou informar ao compilador que não pode lidar com isso declarando que seu método lança essa exceção, então o código que usa seu método terá que lidar com essa exceção (mesmo Também pode optar por declarar que ele lança a exceção se não conseguir lidar com isso).

O compilador verificará que fizemos uma das duas coisas (capturar ou declarar).Portanto, estes são chamados de exceções verificadas.Mas erros e exceções de tempo de execução não são verificadas pelo compilador (mesmo que você possa optar por pegar ou declarar, isso não é necessário).Então, esses dois são chamados de exceções desmarcadas.

Os erros são usados para representar as condições que ocorrem fora da aplicação, como a falha do sistema.As exceções de tempo de execução geralmente ocorrem por falha na lógica do aplicativo.Você não pode fazer nada nessas situações.Quando a exceção do tempo de execução ocorre, você deve reescrever o código do seu programa.Portanto, estes não são verificados pelo compilador.Essas exceções de tempo de execução descobrirão em desenvolvimento e período de teste.Em seguida, temos que refatorar nosso código para remover esses erros.

A regra que uso é:nunca use exceções não verificadas!(ou quando você não vê nenhuma maneira de contornar isso)

Há um argumento muito forte para o oposto:Nunca use exceções verificadas.Estou relutante em tomar partido no debate, mas parece haver um amplo consenso de que a introdução de exceções verificadas foi uma decisão errada em retrospectiva.Por favor, não atire no mensageiro e consulte aqueles argumentos.

Em qualquer sistema grande o suficiente, com muitas camadas, exceções verificadas são inúteis, pois, de qualquer forma, você precisa de uma estratégia de nível arquitetural para lidar com como a exceção será tratada (use uma barreira de falhas)

Com exceções verificadas, sua estratégia de tratamento de erros é microgerenciada e é insuportável em qualquer sistema grande.

Na maioria das vezes você não sabe se um erro é "recuperável" porque não sabe em que camada o chamador da sua API está localizado.

Digamos que eu crie uma API StringToInt que converte a representação de string de um número inteiro em um Int.Devo lançar uma exceção verificada se a API for chamada com a string "foo"?É recuperável?Não sei porque em sua camada o chamador da minha API StringToInt já pode ter validado a entrada, e se esta exceção for lançada, é um bug ou uma corrupção de dados e não é recuperável para esta camada.

Neste caso o chamador da API não deseja capturar a exceção.Ele só quer deixar a exceção “borbulhar”.Se eu escolher uma exceção verificada, esse chamador terá muitos blocos catch inúteis apenas para relançar artificialmente a exceção.

O que é recuperável depende na maioria das vezes do chamador da API, não do autor da API.Uma API não deve usar exceções verificadas, pois apenas exceções não verificadas permitem escolher entre capturar ou ignorar uma exceção.

Você está certo.

Exceções não verificadas são usados para deixar o sistema falhar rápido O que é uma boa coisa.Você deve indicar claramente o que seu método espera para funcionar corretamente.Dessa forma, você pode validar a entrada apenas uma vez.

Por exemplo:

/**
 * @params operation - The operation to execute.
 * @throws IllegalArgumentException if the operation is "exit"
 */
 public final void execute( String operation ) {
     if( "exit".equals(operation)){
          throw new IllegalArgumentException("I told you not to...");
     }
     this.operation = operation; 
     .....  
 }
 private void secretCode(){
      // we perform the operation.
      // at this point the opreation was validated already.
      // so we don't worry that operation is "exit"
      .....  
 }

Só para dar um exemplo.A questão é que, se o sistema falhar rapidamente, você saberá onde e por que falhou.Você obterá um stacktrace como:

 IllegalArgumentException: I told you not to use "exit" 
 at some.package.AClass.execute(Aclass.java:5)
 at otherPackage.Otherlass.delegateTheWork(OtherClass.java:4569)
 ar ......

E você saberá o que aconteceu.A OtherClass no método "delegateTheWork" (na linha 4569) chamou sua classe com o valor "exit", mesmo quando não deveria, etc.

Caso contrário, você teria que espalhar validações por todo o seu código e isso estaria sujeito a erros.Além disso, às vezes é difícil rastrear o que deu errado e você pode esperar horas de depuração frustrante

A mesma coisa acontece com NullPointerExceptions.Se você tem uma classe de 700 linhas com cerca de 15 métodos, que usa 30 atributos e nenhum deles pode ser nulo, em vez de validar em cada um desses métodos a nulidade, você pode tornar todos esses atributos somente leitura e validá-los no construtor ou método de fábrica.

 public static MyClass createInstane( Object data1, Object data2 /* etc */ ){ 
      if( data1 == null ){ throw NullPointerException( "data1 cannot be null"); }

  }


  // the rest of the methods don't validate data1 anymore.
  public void method1(){ // don't worry, nothing is null 
      ....
  }
  public void method2(){ // don't worry, nothing is null 
      ....
  }
  public void method3(){ // don't worry, nothing is null 
      ....
  }

Exceções verificadas São úteis quando o programador (você ou seus colegas de trabalho) fez tudo certo, validou a entrada, executou testes e todo o código está perfeito, mas o código se conecta a um webservice de terceiro que pode estar fora do ar (ou a um arquivo que você estava using foi excluído por outro processo externo, etc.).O webservice pode até ser validado antes da tentativa de conexão, mas durante a transferência de dados algo deu errado.

Nesse cenário, não há nada que você ou seus colegas de trabalho possam fazer para ajudar.Mas ainda assim você tem que fazer alguma coisa e não deixar o aplicativo morrer e desaparecer aos olhos do usuário.Você usa uma exceção verificada para isso e trata a exceção, o que você pode fazer quando isso acontece?, na maioria das vezes, apenas para tentar registrar o erro, provavelmente salve seu trabalho (o aplicativo funciona) e apresente uma mensagem ao usuário .(O site blabla está fora do ar, tente novamente mais tarde, etc.)

Se a exceção verificada for usada em excesso (adicionando a "exceção de lançamento" em todas as assinaturas de métodos), então seu código se tornará muito frágil, porque todos irão ignorar essa exceção (porque é muito geral) e a qualidade do código será seriamente comprometido.

Se você usar excessivamente a exceção não verificada, algo semelhante acontecerá.Os usuários desse código não sabem se algo pode dar errado e muitos try{...}catch( Throwable t ) aparecerão.

Aqui está minha 'regra prática final'.
Eu uso:

exceção não verificada dentro do código do meu método para um falha devido ao chamador (que envolve um documentação explícita e completa)
exceção verificada para falha devido ao chamado que preciso deixar explícito para quem quiser usar meu código

Compare com a resposta anterior, esta é uma justificativa clara (com a qual se pode concordar ou discordar) para o uso de um ou outro (ou ambos) tipos de exceções.

Para ambas as exceções, criarei minha própria exceção não verificada e marcada para meu aplicativo (uma boa prática, como mencionado aqui), exceto por exceções não verificadas muito comuns (como NullPointerException)

Assim, por exemplo, o objetivo desta função específica abaixo é criar (ou obter, se já existir) um objeto,
significado:

o container do objeto a ser feito/obtido DEVE existir (responsabilidade do CHAMADOR
=> exceção não verificada e limpar comentário javadoc para esta função chamada)
os outros parâmetros não podem ser nulos
(escolha do codificador para colocar isso no CALLER:o codificador não verificará o parâmetro nulo, mas o codificador DOCUMENTA-O)
o resultado NÃO PODE SER NULO
(responsabilidade e escolha do código do chamador, escolha que será de grande interesse para o chamador
=> exceção verificada porque todos os chamadores DEVEM tomar uma decisão se o objeto não puder ser criado/encontrado, e essa decisão deve ser aplicada no momento da compilação:eles não podem usar esta função sem ter que lidar com essa possibilidade, ou seja, com isso verificado exceção).

Exemplo:

/**
 * Build a folder. <br />
 * Folder located under a Parent Folder (either RootFolder or an existing Folder)
 * @param aFolderName name of folder
 * @param aPVob project vob containing folder (MUST NOT BE NULL)
 * @param aParent parent folder containing folder 
 *        (MUST NOT BE NULL, MUST BE IN THE SAME PVOB than aPvob)
 * @param aComment comment for folder (MUST NOT BE NULL)
 * @return a new folder or an existing one
 * @throws CCException if any problems occurs during folder creation
 * @throws AssertionFailedException if aParent is not in the same PVob
 * @throws NullPointerException if aPVob or aParent or aComment is null
 */
static public Folder makeOrGetFolder(final String aFoldername, final Folder aParent,
    final IPVob aPVob, final Comment aComment) throws CCException {
    Folder aFolderRes = null;
    if (aPVob.equals(aParent.getPVob() == false) { 
       // UNCHECKED EXCEPTION because the caller failed to live up
       // to the documented entry criteria for this function
       Assert.isLegal(false, "parent Folder must be in the same PVob than " + aPVob); }

    final String ctcmd = "mkfolder " + aComment.getCommentOption() + 
        " -in " + getPNameFromRepoObject(aParent) + " " + aPVob.getFullName(aFolderName);

    final Status st = getCleartool().executeCmd(ctcmd);

    if (st.status || StringUtils.strictContains(st.message,"already exists.")) {
        aFolderRes = Folder.getFolder(aFolderName, aPVob);
    }
    else {
        // CHECKED EXCEPTION because the callee failed to respect his contract
        throw new CCException.Error("Unable to make/get folder '" + aFolderName + "'");
    }
    return aFolderRes;
}

Não é apenas uma questão de capacidade de recuperação da exceção.O que mais importa, na minha opinião, é se o chamador está interessado em capturar a exceção ou não.

Se você escrever uma biblioteca para ser usada em outro lugar ou uma camada de nível inferior em seu aplicativo, pergunte-se se o chamador está interessado em capturar (conhecer) sua exceção.Se ele não estiver, então use uma exceção não verificada, para não sobrecarregá-lo desnecessariamente.

Esta é a filosofia usada por muitos frameworks.Spring e hibernate, em particular, vêm à mente - eles convertem exceções verificadas conhecidas em exceções não verificadas precisamente porque as exceções verificadas são usadas em excesso em Java.Um exemplo que consigo pensar é o JSONException do json.org, que é uma exceção verificada e é principalmente irritante - deveria estar desmarcada, mas o desenvolvedor simplesmente não pensou nisso.

A propósito, na maioria das vezes o interesse do chamador na exceção está diretamente relacionado à capacidade de recuperação da exceção, mas nem sempre é esse o caso.

Aqui está uma solução muito simples para o seu dilema Marcado/Desmarcado.

Regra 1:Pense em uma exceção não verificada como uma condição testável antes da execução do código.por exemplo…

x.doSomething(); // the code throws a NullPointerException

onde x é nulo...…o código possivelmente deveria ter o seguinte…

if (x==null)
{
    //do something below to make sure when x.doSomething() is executed, it won’t throw a NullPointerException.
    x = new X();
}
x.doSomething();

Regra 2:Pense em uma exceção verificada como uma condição não testável que pode ocorrer enquanto o código é executado.

Socket s = new Socket(“google.com”, 80);
InputStream in = s.getInputStream();
OutputStream out = s.getOutputStream();

…no exemplo acima, o URL (google.com) pode estar indisponível devido ao servidor DNS estar inativo.Mesmo no momento em que o servidor DNS estava funcionando e resolveu o nome ‘google.com’ para um endereço IP, se a conexão fosse feita com google.com, a qualquer momento, a rede poderia cair.Você simplesmente não pode testar a rede o tempo todo antes de ler e gravar nos streams.

Há momentos em que o código simplesmente precisa ser executado antes que possamos saber se há algum problema.Ao forçar os desenvolvedores a escreverem seus códigos de forma a forçá-los a lidar com essas situações por meio de Checked Exception, tenho que tirar meu chapéu para o criador do Java que inventou esse conceito.

Em geral, quase todas as APIs em Java seguem as 2 regras acima.Se você tentar gravar em um arquivo, o disco poderá ficar cheio antes de concluir a gravação.É possível que outros processos tenham feito com que o disco ficasse cheio.Simplesmente não há como testar esta situação.Para aqueles que interagem com hardware onde a qualquer momento o uso do hardware pode falhar, Checked Exceptions parece ser uma solução elegante para esse problema.

Há uma área cinzenta nisso.No caso de muitos testes serem necessários (uma instrução if alucinante com muitos && e ||), a exceção lançada será uma CheckedException simplesmente porque é muito difícil acertar - você simplesmente não pode dizer esse problema é um erro de programação.Se houver muito menos de 10 testes (por ex.‘if (x == null)’), então o erro do programador deve ser uma UncheckedException.

As coisas ficam interessantes quando se lida com intérpretes de idiomas.De acordo com as regras acima, um erro de sintaxe deve ser considerado uma exceção verificada ou não verificada?Eu diria que se a sintaxe da linguagem puder ser testada antes de ser executada, deveria ser uma UncheckedException.Se a linguagem não puder ser testada - semelhante à forma como o código assembly é executado em um computador pessoal, o erro de sintaxe deverá ser uma exceção verificada.

As 2 regras acima provavelmente eliminarão 90% da sua preocupação sobre qual escolher.Para resumir as regras, siga esse padrão… 1) se o código a ser executado puder ser testado antes de ser executado para que ele seja executado corretamente e se ocorrer uma exceção - também conhecida comoum erro do programador, a Exceção deve ser uma UncheckedException (uma subclasse de RuntimeException).2) se o código a ser executado não puder ser testado antes de ser executado para que funcione corretamente, a Exceção deverá ser uma Exceção Verificada (uma subclasse de Exceção).

Você pode chamar isso de exceção verificada ou não verificada;no entanto, ambos tipos de exceção podem ser capturados pelo programador, então a melhor resposta é:escrever todos de suas exceções como desmarcado e documentá-los.Dessa forma, o desenvolvedor que usa sua API pode escolher se deseja capturar aquela exceção e fazer algo.Exceções verificadas são uma completa perda de tempo de todos e tornam seu código um pesadelo chocante de se olhar.O teste de unidade adequado trará quaisquer exceções que você possa precisar capturar e fazer algo.

Exceção verificada:Se o cliente puder se recuperar de uma exceção e quiser continuar, use a exceção verificada.

Exceção desmarcada:Se um cliente não puder fazer nada após a exceção, crie uma exceção não verificada.

Exemplo:Se espera-se que você faça uma operação aritmética em um método A() e com base na saída de A(), você terá que fazer outra operação.Se a saída for nula do método A() que você não espera durante o tempo de execução, espera-se que você lance uma exceção de ponteiro nulo, que é uma exceção de tempo de execução.

Referir aqui

Concordo com a preferência por exceções não verificadas como regra, especialmente ao projetar uma API.O chamador sempre pode optar por capturar uma exceção documentada e não verificada.Você simplesmente não está forçando desnecessariamente o chamador.

Acho as exceções verificadas úteis no nível inferior, como detalhes de implementação.Muitas vezes parece um mecanismo de controle de fluxo melhor do que ter que gerenciar um "código de retorno" de erro especificado.Às vezes, também pode ajudar a ver o impacto de uma ideia para uma alteração de código de baixo nível...declare uma exceção verificada no downstream e veja quem precisaria se ajustar.Este último ponto não se aplica se houver muitos genéricos: pegar(Exceção e) ou lança exceção o que geralmente não é muito bem pensado de qualquer maneira.

Quero compartilhar minha opinião após muitos anos de experiência em desenvolvimento:

Exceção verificada.Isso faz parte do caso de uso de negócios ou do fluxo de chamadas, faz parte da lógica do aplicativo que esperamos ou não.Por exemplo, conexão rejeitada, condição não satisfeita, etc.Precisamos lidar com isso e mostrar a mensagem correspondente ao usuário com instruções sobre o que aconteceu e o que fazer a seguir (tente novamente mais tarde, etc.).Normalmente chamo isso de exceção de pós-processamento ou exceção de "usuário".
Exceção não verificada.Isso faz parte da exceção de programação, algum erro na programação do código de software (bug, defeito) e reflete a maneira como os programadores devem usar a API conforme a documentação.Se um documento lib/framework externo disser que espera obter dados em algum intervalo e não nulos, porque NPE ou IllegalArgumentException serão lançados, o programador deve esperar isso e usar a API corretamente conforme a documentação.Caso contrário, a exceção será lançada.Normalmente chamo isso de exceção de pré-processamento ou exceção de "validação".

Por público-alvo.Agora vamos falar sobre o público-alvo ou grupo de pessoas para as quais as exceções foram criadas (conforme minha opinião):

Exceção verificada.O público-alvo são usuários/clientes.
Exceção não verificada.O público-alvo são desenvolvedores.Em outras palavras, as exceções não verificadas são projetadas apenas para desenvolvedores.

Por fase do ciclo de vida de desenvolvimento do aplicativo.

A exceção verificada foi projetada para existir durante todo o ciclo de vida da produção como um mecanismo normal e esperado que um aplicativo lida com casos excepcionais.
A exceção não verificada foi projetada para existir apenas durante o ciclo de vida de desenvolvimento/teste do aplicativo; todas elas devem ser corrigidas durante esse período e não devem ser lançadas quando um aplicativo já estiver em execução em produção.

A razão pela qual os frameworks geralmente usam exceções não verificadas (Spring, por exemplo) é que o framework não pode determinar a lógica de negócios do seu aplicativo, cabe aos desenvolvedores capturá-los e projetar sua própria lógica.

As exceções verificadas são úteis para casos recuperáveis em que você deseja fornecer informações ao chamador (ou seja,permissões insuficientes, arquivo não encontrado, etc.).

Exceções não verificadas raramente são usadas, ou nunca, para informar o usuário ou programador sobre erros graves ou condições inesperadas durante o tempo de execução.Não os jogue se estiver escrevendo código ou bibliotecas que serão usadas por outras pessoas, pois eles podem não esperar que seu software lance exceções não verificadas, já que o compilador não as força a serem capturadas ou declaradas.

Sempre que uma exceção for menos provável, e pudermos prosseguir mesmo depois de capturá-la, e não pudermos fazer nada para evitar essa exceção, podemos usar a exceção verificada.

Sempre que quisermos fazer algo significativo quando uma exceção específica acontece e quando essa exceção é esperada, mas não certa, podemos usar a exceção verificada.

Sempre que uma exceção navega em camadas diferentes, não precisamos capturá-la em todas as camadas; nesse caso, podemos usar a exceção de tempo de execução ou agrupar a exceção como uma exceção não verificada.

A exceção de tempo de execução é usada quando a exceção tem maior probabilidade de ocorrer, não há como ir mais longe e nada pode ser recuperável.Portanto, neste caso podemos tomar precauções com relação a essa exceção.EX:NUllPointerException, ArrayOutofBoundsException.É mais provável que isso aconteça.Nesse cenário, podemos tomar precauções durante a codificação para evitar tal exceção.Caso contrário, teremos que escrever blocos try catch em todos os lugares.

Exceções mais gerais podem ser feitas. Desmarcadas, menos gerais são marcadas.

Acho que podemos pensar em exceções de várias questões:

por que a exceção acontece?O que podemos fazer quando isso acontecer

por engano, um bug. como um método de objeto nulo é chamado.

String name = null;
... // some logics
System.out.print(name.length()); // name is still null here

Este tipo de exceção deve ser corrigida durante o teste.Caso contrário, a produção será interrompida e você terá um bug muito alto que precisa ser corrigido imediatamente.Este tipo de exceções não precisa ser verificada.

por entrada externa, você não pode controlar ou confiar na saída do serviço externo.

String name = ExternalService.getName(); // return null
System.out.print(name.length());    // name is null here

Aqui, você pode precisar verificar se o nome é nulo se quiser continuar quando for nulo; caso contrário, você pode deixá-lo em paz e ele irá parar aqui e fornecer ao chamador a exceção de tempo de execução.Este tipo de exceções não precisa ser verificada.

por exceção de tempo de execução externa, você não pode controlar ou confiar no serviço externo.

Aqui, você pode precisar capturar todas as exceções de ExternalService se quiser continuar quando isso acontecer; caso contrário, você pode deixá-lo em paz e ele irá parar aqui e fornecer ao chamador a exceção de tempo de execução.

por exceção verificada de externo, você não pode controlar ou confiar no serviço externo.

Neste caso, precisamos saber que tipo de exceção aconteceu no ExternalService? Depende:

se você puder lidar com alguns tipos de exceções, precisará capturá-las e processá-las.Para outros, borbulhe-os.
se você precisar de log ou resposta ao usuário da execução específica, poderá capturá-los.Para outros, borbulhe-os.

Temos que distinguir esses dois tipos de exceção com base no fato de ser um erro do programador ou não.

Se um erro for um erro do programador, deve ser uma exceção não verificada. Por exemplo:SQLException/IOException/NullPointerException.Essas exceções são erros de programação.Eles devem ser tratados pelo programador.Enquanto na API JDBC, a SQLEXCECTION é verificada por exceção, na primavera JDBCTemplate, é uma exceção desmarcada. O Programmer não se preocupa com o SQLEXCECTION, ao usar o Spring.
Se um erro não for um erro do programador e o motivo for externo, deve ser uma Exceção Verificada. Por exemplo:Se o arquivo for excluído ou a permissão do arquivo for alterada por outra pessoa, ele deve ser recuperado.

FileNotFoundException é um bom exemplo para entender diferenças sutis.FileNotFoundException é lançada caso o arquivo não seja encontrado.Existem duas razões para esta exceção.Se o caminho do arquivo for definido pelo desenvolvedor ou obtido do usuário final via GUI, deverá ser uma exceção não verificada.Se o arquivo for excluído por outra pessoa, deverá ser uma Exceção Verificada.

A exceção verificada pode ser tratada de duas maneiras.Eles estão usando try-catch ou propagam a exceção.No caso de propagação de exceção, todos os métodos na pilha de chamadas serão fortemente acoplado por causa do tratamento de exceções.É por isso que temos que usar Checked Exception com cuidado.

Caso você desenvolva um sistema corporativo em camadas, deverá escolher a exceção principalmente não verificada para lançar, mas não se esqueça de usar a exceção verificada caso não possa fazer nada.

Acho que ao declarar a exceção do aplicativo, ela deve ser uma exceção não verificada, ou seja, uma subclasse de RuntimeException.O motivo é que ele não sobrecarregará o código do aplicativo com declarações try-catch e lançamentos no método.Se o seu aplicativo estiver usando Java Api, que lança exceções verificadas que precisam ser tratadas de qualquer maneira.Para outros casos, o aplicativo pode lançar uma exceção não verificada.Se o chamador do aplicativo ainda precisar lidar com exceções não verificadas, isso poderá ser feito.

A regra que uso é:nunca use exceções não verificadas!(ou quando você não vê nenhuma maneira de contornar isso)

Do ponto de vista do desenvolvedor que usa sua biblioteca ou do usuário final que usa sua biblioteca/aplicativo, é realmente uma pena ser confrontado com um aplicativo que trava devido a uma exceção não detectada.E contar com uma solução abrangente também não é bom.

Dessa forma, o usuário final ainda pode receber uma mensagem de erro, em vez de o aplicativo desaparecer completamente.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow