Quando pegar java.lang.Error?

votos
101

Em que situações se deve pegar java.lang.Errorem um aplicativo?

Publicado 09/12/2008 em 14:56
fonte usuário
Em outras línguas...                            


16 respostas

votos
87

Geralmente, não. No entanto, às vezes você precisa pegar erros específicos.

Se você estiver escrevendo código do framework-ish (carregamento aulas 3rd party), pode ser sábio para pegar LinkageErrors (nenhuma classe def encontrados, ligação insatisfeito, mudança de classe incompatível). Eu também vi alguns códigos 3rd-festa estúpida jogando sublcasses de erros, então você vai ter que lidar com estes também.

By the way, eu não tenho certeza que não é possível recuperar de OutOfMemory.

Respondeu 09/12/2008 em 15:12
fonte usuário

votos
46

Nunca. Você nunca pode ter certeza de que o aplicativo é capaz de executar a próxima linha de código. Se você receber um OutOfMemoryError, você tem nenhuma garantia de que você será capaz de fazer nada de forma confiável . Pegar RuntimeException e exceções verificadas, mas nunca erros.

http://pmd.sourceforge.net/rules/strictexception.html

Respondeu 09/12/2008 em 15:00
fonte usuário

votos
16

Geralmente você deve sempre pegar java.lang.Errore escrevê-lo em um log ou exibi-lo para o usuário. Eu trabalho em apoio e veja diariamente que os programadores não pode dizer o que aconteceu em um programa.

Se você tiver um fio daemon, então você deve evitar que seja encerrado. Em outros casos, o aplicativo irá funcionar corretamente.

Você só deve pegar java.lang.Errorno mais alto nível.

Se você olhar para a lista de erros que você vai ver que a maioria pode ser tratada. Por exemplo, um ZipErrorocorre na leitura de arquivos zip corruptos.

Os erros mais comuns são OutOfMemoryErrore NoClassDefFoundError, ambos, na maioria dos casos os problemas de tempo de execução.

Por exemplo:

int length = Integer.parseInt(xyz);
byte[] buffer = new byte[length];

pode produzir um OutOfMemoryError, mas é um problema de tempo de execução e não há razão para encerrar seu programa.

NoClassDefFoundErrorocorrem principalmente se uma biblioteca não está presente ou se você trabalha com outra versão Java. Se é uma parte opcional do seu programa, então você não deve encerrar o seu programa.

Eu posso dar muitos mais exemplos de por que é uma boa idéia para pegar Throwableno nível superior e produzir uma mensagem de erro útil.

Respondeu 05/03/2009 em 13:29
fonte usuário

votos
14

No ambiente multithreaded, você na maioria das vezes quiser pegá-lo! Quando você pegá-lo, registrá-lo e terminar aplicativo inteiro! Se você não fizer isso, alguns segmento que poderia estar fazendo alguma parte crucial seria morto, e resto da aplicação vai pensar que tudo é normal. Fora disso, muitas situações indesejadas pode acontecer. Um menor problema é que você não seria capaz de encontrar facilmente raiz do problema, se outros tópicos começar a atirar algumas exceções por causa de um segmento não trabalho.

Por exemplo, geralmente loop deve ser:

try {
   while (shouldRun()) {
       doSomething();
   }
}
catch (Throwable t) {
   log(t);
   stop();
   System.exit(1);
}

Mesmo em alguns casos, você iria querer lidar com erros diferentes de forma diferente, por exemplo, em OutOfMemoryError você seria capaz de fechar a aplicação regularmente (talvez até mesmo liberar memória, e continuar), em alguns outros, não há muito que você pode fazer.

Respondeu 07/03/2009 em 17:39
fonte usuário

votos
7

Muito raramente.

Eu diria apenas no nível superior de um fio, a fim de tentar emitir uma mensagem com a razão para uma morte rosca.

Se você estiver em uma estrutura que faz esse tipo de coisa para você, deixe-o ao quadro.

Respondeu 09/12/2008 em 15:15
fonte usuário

votos
6

Se você é louco o suficiente para ser a criação de um novo quadro de teste de unidade, o corredor de teste provavelmente terá que pegar java.lang.AssertionError jogado por qualquer casos de teste.

Caso contrário, consulte outras respostas.

Respondeu 10/12/2008 em 21:44
fonte usuário

votos
6

Um Errornormalmente não deve ser capturado , pois indica uma condição anormal que nunca deve ocorrer .

A partir da especificação API Java para a Errorclasse:

Um Erroré uma subclasse de Throwable que indica problemas sérios que uma aplicação razoável não deve tentar pegar. A maioria desses erros são condições anormais. [...]

Um método não é obrigado a declarar no seu cláusula throws quaisquer subclasses de erro que podem ser geradas durante a execução do método, mas não travados, uma vez que estes erros são condições anormais que nunca deve ocorrer.

Como a especificação menciona, uma Errorsó é jogado em circunstâncias que são possibilidades são, quando um Errorocorre, há muito pouco a aplicação pode fazer, e, em algumas circunstâncias, o Java Virtual própria máquina pode estar em um estado instável (como VirtualMachineError)

Embora um Erroré uma subclasse Throwabledo que significa que ele pode ser pego por uma try-catchcláusula, mas provavelmente não é realmente necessário, como a aplicação será em um estado anormal quando uma Erroré lançada pelo JVM.

Há também uma pequena seção sobre este tema na Seção 11.5 A hierarquia de exceções do Java Language Specification, 2nd Edition .

Respondeu 09/12/2008 em 15:18
fonte usuário

votos
6

Quase nunca. Erros são projetados para serem questões que as aplicações em geral, não pode fazer nada a respeito. A única exceção pode ser para lidar com a apresentação do erro, mas mesmo isso pode não saem como planejado dependendo do erro.

Respondeu 09/12/2008 em 14:59
fonte usuário

votos
5

E há um par de outros casos em que se você pegar um erro, você tem que relançar-lo . Por exemplo ThreadDeath nunca deve ser capturado, ele pode causar grande problema é que você pegá-lo em um ambiente fechado (por exemplo, um servidor de aplicativos.):

Um aplicativo deve pegar instâncias desta classe somente se ele deve limpar depois de ser terminada de forma assíncrona. Se ThreadDeath é capturado por um método, é importante que seja relançada para que o segmento realmente morre.

Respondeu 09/12/2008 em 15:09
fonte usuário

votos
4

Muito, muito raramente.

Eu fiz isso apenas para uma casos conhecidos muito específicas. Por exemplo, java.lang.UnsatisfiedLinkError poderia ser jogar se dois independência ClassLoader carga mesma DLL. (Concordo que deve mover o JAR a um carregador de classe compartilhada)

Mas o caso mais comum é que você precisava de login, a fim de saber o que aconteceu quando o usuário venha a reclamar. Você quer uma mensagem ou um pop-up para o usuário, em vez de silêncio morto.

Mesmo programador em C / C ++, eles pop um erro e dizer algo que as pessoas não entendem antes de saída (por exemplo, falha de memória).

Respondeu 09/12/2008 em 15:28
fonte usuário

votos
3

que é bastante útil para pegar java.lang.AssertionError em um ambiente de teste ...

Respondeu 27/11/2013 em 02:53
fonte usuário

votos
3

Em um aplicativo Android que eu estou pegando um java.lang.VerifyError . Uma biblioteca que estou usando não irá funcionar em dispositivos com uma versão antiga do sistema operacional e do código da biblioteca vai jogar como um erro. Eu poderia, naturalmente, evitar o erro, verificando a versão do sistema operacional em tempo de execução, mas:

  • O SDK mais antigo suportado pode mudar no futuro para a biblioteca específica
  • O bloco de erro try-catch é parte de uma maior caindo para trás mecanismo. Alguns dispositivos específicos, embora eles deveriam apoiar a biblioteca, lançar exceções. I pegar VerifyError e todas as exceções de usar uma solução de volta queda.
Respondeu 14/03/2013 em 07:17
fonte usuário

votos
2

Idealmente, não devem manusear / erros de captura. Mas pode haver casos em que precisamos fazer, com base na exigência de quadro ou de aplicação. Digamos que eu tenha um daemon Analisador XML que implementa DOM Parser que consome mais memória. Se há uma exigência como um fio Analisador não deve ser morreram quando fica OutOfMemoryError , em vez disso, deve segurá-lo e enviar uma mensagem / mail para o administrador de application / quadro.

Respondeu 05/05/2014 em 19:22
fonte usuário

votos
1

Há um erro quando a JVM não mais está funcionando como esperado, ou está na iminência de. Se você pegar um erro, não há garantia de que o bloco catch será executado, e menos ainda que ele será executado até o fim.

Ele também irá depender do computador de corrida, o estado atual de memória, por isso não há maneira de testar, e tentar fazer o seu melhor. Você só vai ter um resultado hasardous.

Você também vai rebaixar a legibilidade do seu código.

Respondeu 23/04/2013 em 17:50
fonte usuário

votos
1

Pode ser apropriado para pegar erro dentro testes de unidade que verificam uma afirmação é feita. Se alguém desativa afirmações ou não exclui a afirmação de que você gostaria de saber

Respondeu 19/08/2012 em 21:35
fonte usuário

votos
1

Idealmente, nós nunca deve pegar erro em nossa aplicação Java, pois é uma condição anormal. A aplicação estaria em estado anormal e poderia resultar em carshing ou dar algum resultado seriamente errado.

Respondeu 26/01/2011 em 07:23
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more