Tendo trabalhado com exceções em Java e .NET E depois de ler muitos artigos sobre como / quando / por que capturar exceções, finalmente cheguei às etapas a seguir que passo em minha cabeça sempre que vejo uma possível exceção acontecendo, ou um exceção eu devo pegar (Java) ... mesmo que isso nunca aconteça (suspiro ...). E parece estar funcionando, pelo menos para mim:
- Existe algo útil que eu possa fazer com essa exceção (exceto o log)? Se a resposta for sim, escreva o código da solução alternativa e, se a solução alternativa gerar exceções, vá para 2:
- Envolva a exceção em torno de uma exceção de tempo de execução, ative-a e vá para 3.
- Na classe de nível superior em que uma possível transação de banco de dados / processo foi iniciada, capture a exceção, faça a reversão da transação e repita a exceção.
- Na classe de nível superior (que pode ser aquela em que a transação foi iniciada), registre a exceção usando uma estrutura de log como slf4j (juntamente com log4j por exemplo) ou log4net . Se possível, envie diretamente a exceção por email para uma lista de distribuição composta por desenvolvedores do aplicativo.
- Se houver uma GUI, exiba uma mensagem de erro indicando da maneira mais amigável ao usuário o que causou o problema; não exibe a exceção / rastreamento de pilha, o usuário não se importa e não precisa saber que era uma NullPointerException.
Devo também adicionar a etapa 0 , onde propositalmente estou lançando o que chamo de exceção "comercial" (uma nova exceção criada ao estender a classe "Exception") quando algum tratamento complexo não pode ser executado devido a erros de dados, MAS é conhecido por acontecer, pois foram identificados como casos de exceção durante a análise.
Exceto pela parte de registro, concordo plenamente com os pontos escritos por "mikera"; Vou apenas acrescentar que a exceção deve ser registrada apenas uma vez .
Além disso, as etapas listadas podem ser diferentes se o que você está escrevendo é uma API / Framework . Lá, lançar exceções bem projetadas é obrigatório para ajudar os desenvolvedores a entender seus erros.
Quanto ao teste das exceções, usando objetos simulados, você deve poder testar quase tudo, seja ele excepcional ou não, desde que suas classes respeitem a melhor prática "uma classe para fazer uma coisa". Pessoalmente, também certifico-me de marcar os métodos mais importantes, mas ocultos, como "protegidos" em vez de "privados", para que eu possa testá-los sem muito trabalho. Além disso, testar exceções é simples, apenas provoque a exceção e "espere" que uma exceção ocorra capturando-a. Se você não receber uma exceção, terá um erro de caso de teste de unidade.