A apanhar os erros do Java

Ouvi dizer que apanhar é considerado uma má prática. Estou a carregar um .dll que não está garantido estar no caminho, e gostaria de mudar para um local configurado pelo usuário no caso de não estar.

try {
    System.loadLibrary("HelloWorld");
} catch(UnsatisfiedLinkError ule){
    System.load("C:/libraries/HelloWorld.dll");
}
Há uma maneira melhor de fazer isto? Ou apanhar o {[2] } aqui é aceitável?

Author: ilanco, 2012-06-13

4 answers

Para além de dar conselhos sobre como superar tecnicamente o problema, gostaria de tirar um momento e explicar porque é considerado "má prática" em primeiro lugar. Vamos começar por esclarecer qual é a classe.

Em java, erros e exceções (que são os principais tipos) são lançados. Atirar uma das opções acima é feito usando a palavra-chave throw. Cada classe que estende o básico java.lang.Throwable pode ser lançada.

Há duas classes que herdar da classe básica Throwable: Exception e Error. A diferença entre esses dois é explicada em suas documentações:

Um Erro é uma subclasse de Throwable que indica grave problemas que uma aplicação razoável não deve tentar apanhar. Mais tais erros são condições anormais. [...]

Origem

A excepção da classe e as suas subclasses são uma forma de Throwable que indica condições que uma aplicação razoável pode querer pegar.

Origem


Como explicado acima, os erros e exceções são separados por causa de suas origens diferentes. Um {[0] } normalmente indica um problema, que o pedido não pode recuperar de. Portanto, não devem ser apanhados.

O mesmo é verdade para um RuntimeException, mas é usado para indicar um problema com um camada de alto nível (por exemplo, métodos). Considerando que o Error indica um problema de baixo nível (por exemplo, o tempo de execução).


Então, agora que você entendeu que só pegará exceções e erros que você é capaz de recuperar de , a resposta à sua pergunta deve ser clara.

Sim, é perfeitamente razoável apanhar o UnsatisfiedLinkError, porque a sua aplicação pode recuperar dele.


([11]) informação num artigo no meu Blog.
 23
Author: Lukas Knuth, 2016-12-07 10:26:35

Só deve apanhar erros em casos muito específicos. Somente pegar e errar se você tiver explorado todas as outras possibilidades. Concordo plenamente com tudo o que o Lukas Knuth disse. Mas tenho uma pequena adição. No caso de você pegar qualquer tipo de erro, certifique-se de que você pegar erros do mais estreito um escopo como você pode. Além disso, se possível, certifique-se de que os métodos em que você pegar erros são declarados como finais. A razão é que os erros de captura geralmente podem levar a alguns programas muito shaky. Considere que você pegar um erro em um método que é mais tarde estendido para chamar outros métodos, todos esses métodos subjacentes agora também teria erros capturados (não intencionalmente) pela captura sobrelotação.

Se precisares de apanhar um erro, fá-lo de forma estreita e controlada.
 1
Author: Martin Nielsen, 2014-09-18 09:36:19
O LoadLibrary chama findLibrary() o que seria útil, mas está protegido, a sua melhor aposta é escrever a sua própria classe estendendo ClassLoader. O carregador de classe tem um método protegido chamado findLibrary() que irá retornar o caminho para uma biblioteca ou nulo se não existir. Dessa forma você pode apenas verificar para nulo em vez de erros de captura. Eu não tenho certeza se isso é realmente "melhor", mas ele vai remover a sua necessidade de tentar a captura;
 0
Author: Jordon Biondo, 2012-06-13 14:58:54

Se você está codificando defensivamente e pode se recuperar de um problema, então não é um Java Error. Se tal problema não for muito provável, então crie uma subclasse de Exception e jogue e pegue isso. Se tal problema é provável, então ele nem deve lançar um Exception; mas, deve ser parte do fluxo de código regular.

try {
  if (config.hasCustomDLL()) {
    System.load(config.getCustomDLL());
  } else {
    System.loadLibrary(Config.DEFAULT_DLL);
  }
} catch (UnstatisfiedLinkError e) {
  System.out.println("Error loading DLL: " + e);
}

Errors são feitos para fracassos realmente maus, não recuperáveis "fracassos" que realmente não são mesmo fracassos se houver uma solução adequada. Não sobrecarregues o sistema. projetado para lidar com falhas com o que equivale a uma capacidade de configurar o sistema de várias maneiras.

 0
Author: Edwin Buck, 2012-06-13 16:20:24