Não use printStackTrace () para código online
Depois de escrever o código, verifique-o. Não tenha printStackTrace () no código. Como printStackTrace () só exibirá as informações de pilha incorretas no console, ele só é adequado para depuração de código.
Se você realmente precisa registrar exceções, use o registro.
Nunca engula exceções em blocos catch
catch (NoSuchMethodException e) {
return null;
}Nunca não trate a exceção, mas retorne null, para que a exceção seja engolida e nenhuma informação de falha possa ser obtida, o que trará grandes dificuldades para futuras soluções de problemas.
Declarar exceções específicas verificadas quando necessário
public void foo() throws Exception { //错误做法
}O código acima deve ser evitado tanto quanto possível, porque seu chamador não tem ideia de qual é a causa do erro.
Na declaração do método, algumas exceções verificadas específicas podem ser lançadas pelo método. Se houver vários, lance vários separadamente, de modo que o usuário desse método faça o processamento específico para cada exceção separadamente, a fim de evitar falha.
public void foo() throws SpecificException1, SpecificException2 {
//正确做法
}
### 始终只捕获那些可以处理的异常
catch (NoSuchMethodException e)
{
throw e; //这代码一点用都没有
}Este é um conceito básico. Quando você pode manipulá-lo, você captura a exceção novamente, caso contrário, nunca deveria capturá-la.
Se você não puder segurá-lo no bloco de captura, não o pegue primeiro e depois jogue-o diretamente, não faz sentido.
Tente capturar subclasses específicas em vez de capturar diretamente a classe Exception
try {
someMethod();
}
catch (Exception e)
{
LOGGER.error("method has failed", e);
}O maior problema com o código acima é se o desenvolvedor de someMethod () adiciona uma exceção específica a ele e espera-se que o chamador possa tratá-la especialmente.
No entanto, se o chamador capturar diretamente a classe Exception, ele nunca saberá as alterações específicas de someMethod. Isso pode fazer com que o programa trave em um determinado ponto do processo em execução.
Nunca pegue a classe Throwable
Este é um problema sério, porque Error em Java também pode ser uma subclasse de Throwable. Mas o erro está além do controle da própria máquina virtual Java. A máquina virtual Java pode nem mesmo solicitar a cláusula catch do usuário quando há algum erro.
Sempre sobrescrever a exceção original na exceção personalizada para que o rastreamento da pilha não seja perdido
catch (NoSuchMethodException e)
{
throw new MyServiceException("Some information: " + e.getMessage()); //错误做法
}O comando acima pode perder o rastreamento da pilha da exceção principal. A maneira correta é:
catch (NoSuchMethodException e) {
throw new MyServiceException("Some information: " , e); //正确做法
}
Você pode registrar exceções ou lançar exceções, mas não faça os dois
catch (NoSuchMethodException e) {
LOGGER.error("Some information", e);
throw e;
}Conforme mostrado no código acima, o lançamento e o registro podem produzir várias mensagens de registro no arquivo de registro.
Isso levará ao mesmo problema, mas existem muitas mensagens de erro diferentes no log, causando confusão entre os desenvolvedores.
Nunca lance uma exceção finalmente
try {
someMethod(); //抛出 exceptionOne
}
finally
{
cleanUp(); //如果在这里再抛出一个异常，那么try中的exceptionOne将会丢失forever
}
在上面的例子中，如果someMethod()抛出一个异常，并且在finally块中，cleanUp()也抛出一个异常，那么初始的exceptionOne(正确的错误异常)将永远丢失。
Se você não pretende lidar com exceções, use finally block em vez de catch block
try {
someMethod();
}
finally
{
cleanUp();
}Esta também é uma boa prática. Se você acessar outros métodos em seu método, e o método lançar uma exceção e você não quiser tratá-lo, mas ainda precisar fazer algum trabalho de limpeza, limpe no bloco finally. Não use blocos de captura.
