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

Em Java (ou qualquer outro idioma com exceções verificadas), ao criar sua própria class de exceção, como você decide se deve ser marcado ou desmarcado?

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

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 ruins.

Exceções verificadas devem ser usadas para erros previsíveis , mas inevitáveis , dos quais é razoável se recuperar .

Exceções não verificadas devem ser usadas para todo o resto.

Eu vou quebrar isso para você, porque a maioria das pessoas não entende o que isso significa.

  1. Previsível, mas imprevisível : o chamador fez tudo ao seu alcance para validar os parâmetros de input, mas algumas condições fora do controle fizeram com que a operação falhasse. Por exemplo, você tenta ler um arquivo, mas alguém o exclui entre a hora em que você verifica se ele existe e a hora em que a operação de leitura começa. Ao declarar uma exceção verificada, você está dizendo ao chamador para antecipar essa falha.
  2. Razoável para recuperar : Não há sentido em dizer aos chamadores para antecipar exceções que eles não podem recuperar. Se um usuário tentar ler de um arquivo não existente, 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 buggy), 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 mais tarde.

A menos que a exceção que você está jogando atenda a todas as condições acima, ela deve usar uma exceção não verificada.

Reavaliar em todos os níveis : às vezes, o método que captura a exceção verificada não é o local correto para lidar com 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, você deverá lançar uma exceção verificada por conta própria. Caso contrário, você deve agrupar a exceção em uma exceção não verificada. Se você seguir esta regra, estará convertendo as exceções verificadas em exceções não verificadas e vice-versa, dependendo de qual camada você está.

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

De um aprendiz de Java :

Quando ocorre uma exceção, você precisa capturar e manipular a exceção ou dizer ao compilador que não pode manipulá-la, declarando que seu método gera essa exceção, então o código que usa seu método terá que manipular essa exceção (até mesmo também pode optar por declarar que lança a exceção se não puder lidar com isso).

O compilador verificará se fizemos uma das duas coisas (capturar ou declarar). Então, essas são chamadas de exceções verificadas. Mas os Erros e Exceções de Tempo de Execução não são verificados pelo compilador (mesmo que você possa escolher capturar ou declarar, isso não é necessário). Então, esses dois são chamados de exceções não verificadas.

Erros são usados ​​para representar as condições que ocorrem fora do aplicativo, como falha do sistema. 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 de tempo de execução ocorre, você precisa rewrite seu código de programa. Então, estes não são verificados pelo compilador. Essas exceções de tempo de execução serão descobertas no desenvolvimento e no período de teste. Então 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 caso 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 se refira a esses argumentos .

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

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

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

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

Nesse caso, o chamador da API não deseja capturar a exceção. Ele só quer que a exceção “borbulhe”. Se eu escolher uma exceção verificada, esse chamador terá um bloco de captura inútil apenas para relançar artificialmente a exceção.

O que é recuperável depende, na maioria das vezes, do responsável pela chamada da API, e não do autor da API. Uma API não deve usar exceções verificadas, pois somente as exceções não verificadas permitem escolher capturar ou ignorar uma exceção.

Você está certo.

Exceções não verificadas são usadas para deixar o sistema falhar rapidamente, o que é uma coisa boa. Você deve indicar claramente o que seu método está esperando para funcionar corretamente. Desta forma, você pode validar a input 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" ..... } 

Apenas para dar um exemplo. A questão é que, se o sistema falhar rapidamente, você saberá onde e por que ele 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. O OtherClass no método “delegateTheWork” (na linha 4569) chamou sua class com o valor “exit”, mesmo quando não deveria, etc.

Caso contrário, você teria que aplicar validações em todo o seu código, o que é propenso a erros. Além disso, às vezes é difícil rastrear o que deu errado e você pode esperar horas de debugging frustrante

A mesma coisa acontece com o NullPointerExceptions. Se você tem uma class de 700 linhas com cerca de 15 methods, que usa 30 atributos e nenhum deles pode ser nulo, em vez de validar em cada um desses methods a capacidade de anulação, 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 input, executou testes e todo o código é perfeito, mas o código se conecta a um serviço da web de terceiros que pode estar inativo (ou um arquivo você estava usando foi excluído por outro processo externo etc). O webservice pode até ser validado antes que a conexão seja tentada, 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 ajudá-lo. Mas você ainda tem que fazer alguma coisa e não deixar o aplicativo morrer e desaparecer nos olhos do usuário. Você usa uma exceção verificada para isso e manipula a exceção, o que você pode fazer quando isso acontece ?, na maioria das vezes, apenas para tentar registrar o erro, provavelmente salvar seu trabalho (o trabalho de aplicativo) e apresentar uma mensagem para o usuário . (O site blabla está desativado, por favor tente mais tarde etc.)

Se a exceção verificada for usada em demasia (adicionando a “throw Exception” em todas as assinaturas de methods), seu código ficará 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 tentar muito {…} catch (Throwable t) aparecerá.

Aqui está a minha ‘regra final’.
Eu uso:

  • exceção não verificada dentro do código do meu método para uma falha devido ao chamador (que envolve uma documentação explícita e completa )
  • Exceção verificada para uma falha devido ao candidato que preciso tornar explícito para qualquer pessoa que queira usar meu código

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


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

Então, por exemplo, o objective desta function específica abaixo é fazer (ou obter se já existir) um object,
significado:

  • o recipiente do object para fazer / obter DEVE existir (responsabilidade do CHAMADOR)
    => exceção não verificada, e limpar comentário javadoc para esta function chamada)
  • os outros parâmetros não podem ser nulos
    (escolha do codificador para colocar isso no CALLER: o codificador não irá verificar o parâmetro nulo mas o codificador DOCUMENT IT)
  • o resultado NÃO PODE SER NULO
    (responsabilidade e escolha do código do candidato, escolha que será de grande interesse para o chamador
    => Exceção checada porque todos os chamadores DEVEM tomar uma decisão se o object não puder ser criado / encontrado, e essa decisão deve ser aplicada no tempo de compilation: eles não podem usar esta function sem ter que lidar com esta possibilidade, significando isto exceção).

Exemplo:


 /** * Build a folder. 
* 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 se recuperar da exceção. O que mais importa, na minha opinião, é se o interlocutor está interessado em pegar 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 a si mesmo se o chamador está interessado em capturar (sabendo sobre) sua exceção. Se ele não estiver, use uma exceção não verificada, para não sobrecarregá-lo desnecessariamente.

Essa é a filosofia usada por muitos frameworks. Spring e hibernate, em particular, vêm à mente – eles convertem exceção verificada conhecida em exceção não verificada precisamente porque exceções verificadas são usadas em demasia em Java. Um exemplo que eu posso pensar é o JSONException do json.org, que é uma exceção verificada e é na maior parte chato – deve ser desmarcado, mas o desenvolvedor simplesmente não pensou nisso.

By the way, na maioria das vezes o interesse do chamador na exceção está diretamente correlacionado com a capacidade de recuperar a exceção, mas isso nem sempre é o caso.

Você pode chamá-lo de uma exceção marcada ou desmarcada; no entanto, os dois tipos de exceção podem ser capturados pelo programador, portanto, a melhor resposta é: gravar todas as suas exceções como desmarcadas e documentá-las. Dessa forma, o desenvolvedor que usa sua API pode escolher se deseja capturar essa exceção e fazer alguma coisa. Exceções verificadas são um completo desperdício de tempo de todos e faz seu código um pesadelo chocante de se olhar. O teste unitário adequado apresentará as exceções que você pode ter para pegar e fazer alguma coisa.

Aqui está uma solução muito simples para o seu dilema Checked / Unchecked.

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 deve 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 instante em que o servidor DNS estava funcionando e resolvia o nome “google.com” para um endereço IP, se a conexão fosse feita para google.com, a qualquer momento, a rede poderia ficar inativa. Você simplesmente não pode testar a rede o tempo todo antes de ler e gravar em streams.

Há momentos em que o código simplesmente deve ser executado antes que possamos saber se há algum problema. Ao forçar os desenvolvedores a escrever seu código de forma a forçá-los a lidar com essas situações através da Checked Exception, tenho que dar uma olhada no criador do Java que inventou esse conceito.

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

Há uma área cinza para isso. No caso em que muitos testes são necessários (uma declaração que explode com muito && e ||), a exceção lançada será uma CheckedException simplesmente porque é muito difícil de acertar – você simplesmente não pode dizer este problema é um erro de programação. Se houver muito menos de 10 testes (por exemplo, ‘if (x == null)’), o erro do programador deverá ser 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 Desmarcada? Eu diria que se a syntax da linguagem puder ser testada antes de ser executada, ela deve ser uma UncheckedException. Se o idioma não puder ser testado – semelhante a como o código assembly é executado em um computador pessoal, o erro de syntax deve ser uma exceção verificada.

As 2 regras acima provavelmente removerão 90% da sua preocupação sobre qual escolher. Para resumir as regras, siga este padrão … 1) se o código a ser executado puder ser testado antes de ser executado para que seja executado corretamente e se ocorrer uma Exceção – também conhecido como erro do programador, a Exceção deve ser UncheckedException (uma subclass de RuntimeException). ). 2) se o código a ser executado não puder ser testado antes de ser executado para que seja executado corretamente, a Exceção deverá ser uma Exceção verificada (uma subclass de Exceção).

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

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

Exemplo: Se espera-se que você faça operações aritméticas em um método A () e com base na saída de A (), você terá outra operação. Se a saída é nula do método A () que você não está esperando durante o tempo de execução, então é esperado que você ative Exceção de ponteiro nulo, que é Exceção de tempo de execução.

Consulte aqui

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

Eu acho exceções verificadas útil no nível inferior, como detalhes de implementação. Muitas vezes parece um stream melhor do mecanismo de controle do que ter que gerenciar um erro especificado “código de retorno”. Às vezes, também é possível ver o impacto de uma ideia para uma alteração de código de baixo nível … declarar uma exceção verificada e ver quem precisa se ajustar. Este último ponto não se aplica se houver muitos genéricos: catch (Exception e) ou lança Exception que geralmente não é muito bem pensado.

Aqui está eu quero compartilhar minha opinião que tenho após muitos anos de experiência em desenvolvimento:

  1. Exceção marcada. Isso faz parte do caso de uso de negócios ou do stream de chamadas, isso é parte da lógica do aplicativo que esperamos ou não esperamos. Por exemplo, conexão rejeitada, condição não está 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 em seguida (tente novamente mais tarde etc.). Eu costumo chamá-lo de exceção pós-processamento ou exceção “usuário”.

  2. Exceção não verificada. Esta é uma parte da exceção de programação, algum erro na programação de código de software (bug, defeito) e reflete uma maneira como os programadores devem usar a API conforme a documentação. Se um doc / framework externo diz que espera obter dados em algum intervalo e não nulo, porque NPE ou IllegalArgumentException serão lançados, o programador deve esperar e usar a API corretamente conforme a documentação. Caso contrário, a exceção será lançada. Eu normalmente chamo de exceção de pré-processamento ou exceção de “validação”.

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

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

Por fase de ciclo de vida de desenvolvimento de aplicativos.

  1. A exceção verificada é projetada para existir durante todo o ciclo de vida de produção como mecanismo normal e esperado que um aplicativo manipula casos excepcionais.
  2. Exceção não verificada é projetada para existir somente durante o ciclo de vida de desenvolvimento / teste de aplicativo, todos eles devem ser corrigidos durante esse tempo e não devem ser lançados quando um aplicativo já estiver sendo executado na produção.

A razão pela qual as estruturas geralmente usam exceções não verificadas (Spring, por exemplo) é que a estrutura não pode determinar a lógica de negócios de sua aplicação, isso é tarefa dos desenvolvedores capturarem e projetarem a própria lógica.

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

Exceções não verificadas raramente são usadas para informar o usuário ou o programador sobre erros graves ou condições inesperadas durante o tempo de execução. Não os jogue se você estiver escrevendo códigos ou bibliotecas que serão usados ​​por outros, pois eles podem não estar esperando que seu software lance exceções não verificadas, já que o compilador não os força a serem pegos ou declarados.

Sempre que uma exceção é menos provável, e podemos continuar mesmo depois de capturar isso, e não podemos fazer nada para evitar essa exceção, podemos usar a exceção verificada.

Sempre que queremos 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 houver uma exceção navegando 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 a exceção de quebra como exceção não verificada.

Exceção de tempo de execução é usada quando a exceção é mais provável de acontecer, não há como ir mais além e nada pode ser recuperado. Portanto, neste caso, podemos tomar precauções com relação a essa exceção. EX: NUllPointerException, ArrayOutofBoundsException. Estes são mais propensos a acontecer. Nesse cenário, podemos tomar precauções durante a codificação para evitar essa exceção. Caso contrário, teremos que escrever tentar capturar blocos em todo lugar.

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

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

por que a exepção acontece? O que podemos fazer quando acontece

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

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

Esse tipo de exceção deve ser corrigido durante o teste. Caso contrário, ele quebra a produção e você tem um bug muito alto que precisa ser consertado imediatamente. Esse tipo de exceção não precisa ser verificado.

por input 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 você quiser continuar quando é nulo, caso contrário, você pode deixá-lo sozinho e ele irá parar aqui e dar ao chamador a exceção de tempo de execução. Esse tipo de exceção não precisa ser verificado.

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

Aqui, você pode precisar capturar todas as exceções do ExternalService se quiser continuar quando isso acontecer, caso contrário, você poderá deixá-lo em paz e ele será interrompido aqui e concederá 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.

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

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

  1. Se você pode lidar com alguns tipos de exceções, você precisa pegá-los e processá-los. Para outros, borbulhe-os.

  2. Se você precisar de log ou resposta ao usuário a execução específica, você pode pegá-los. Para outros, borbulhe-os.

Eu acho que ao declarar Application Exception deve ser Unchecked Exception, ou seja, subclass de RuntimeException. A razão é que ele não irá confundir o código do aplicativo com try-catch e lançará declaração sobre o método. Se seu aplicativo estiver usando o Java Api, isso gera exceções verificadas que, de qualquer forma, precisam ser manipuladas. Para outros casos, o aplicativo pode lançar exceção não verificada. Se o chamador do aplicativo ainda precisar manipular a exceção não verificada, isso pode ser feito.

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

  • Se um erro for um erro do programador, ele deverá ser uma exceção não verificada . Por exemplo: SQLException / IOException / NullPointerException. Essas exceções são erros de programação. Eles devem ser manipulados pelo programador. Enquanto na API do JDBC, SQLException é Exceção Verificada, Na JDBCTemplate da spring é uma Exceção Não Verificada. O Programador não se preocupa com o SqlException, quando usa o Spring.
  • Se um erro não for um erro do programador e o motivo for proveniente de externo, ele deverá ser uma Exceção verificada. Por exemplo: se o arquivo for excluído ou a permissão do arquivo for alterada por outra pessoa, ela deverá ser recuperada.

FileNotFoundException é um bom exemplo para entender diferenças sutis. FileNotFoundException é lançado no arquivo de caso não encontrado. Existem dois motivos para essa exceção. Se o caminho do arquivo for definido pelo desenvolvedor ou obtido do usuário final via GUI, deve ser uma exceção não verificada. Se o arquivo for excluído por outra pessoa, deve ser uma exceção verificada.

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 methods na pilha de chamadas serão fortemente acoplados devido ao tratamento de exceções. É por isso que temos que usar cuidadosamente a Exceção Verificada.

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

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 usando sua biblioteca ou o usuário final usando sua biblioteca / aplicativo, é realmente uma droga ser confrontado com um aplicativo que falha devido a uma exceção não solicitada. E contar com um pega-tudo 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.

Intereting Posts