reflection object - O que poderia causar java.lang.reflect.InvocationTargetException?




to how (12)

Bem, eu tentei entender e ler o que poderia causar isso, mas eu não consigo entender:

Eu tenho isso em algum lugar no meu código:

 try{
 ..
 m.invoke(testObject);
 ..
 } catch(AssertionError e){
 ...
 } catch(Exception e){
 ..
 }

A coisa é que, quando ele tenta invocar algum método, ele lança InvocationTargetException vez de alguma outra exceção esperada (especificamente ArrayIndexOutOfBoundsException ). Como eu realmente sei qual método é invocado, fui direto para esse código de método e adicionei um bloco try-catch para a linha que ArrayIndexOutOfBoundsException lançava ArrayIndexOutOfBoundsException e realmente lançava ArrayIndexOutOfBoundsException conforme o esperado. No entanto, quando subir, de alguma forma, muda para InvocationTargetException e no código acima catch(Exception e) e é InvocationTargetException e não ArrayIndexOutOfBoundsException conforme o esperado.

O que poderia causar tal comportamento ou como posso verificar uma coisa dessas?


Answers

  1. Listar todos os arquivos jar do modo do Navegador Eclipse
  2. Verifique se todos os arquivos jar estão no modo binário

O erro desapareceu depois que eu fiz Clean-> Run xDoclet-> Run xPackaging.

No meu espaço de trabalho, em ecllipse.


This descreve algo como

InvocationTargetException é uma exceção verificada que envolve uma exceção gerada por um método ou construtor chamado. A partir do release 1.4, essa exceção foi adaptada para se adequar ao mecanismo de encadeamento de exceção de propósito geral. A "exceção de destino" que é fornecida no momento da construção e acessada pelo método getTargetException () agora é conhecida como a causa e pode ser acessada pelo método Throwable.getCause (), bem como pelo "método herdado" mencionado anteriormente.


Use o método getCause() no InvocationTargetException para recuperar a exceção original.


Essa exceção é lançada se o método subjacente (método chamado usando Reflection) lança uma exceção.

Portanto, se o método, que foi chamado pela API de reflexão, lançar uma exceção (como por exemplo, exceção de tempo de execução), a API de reflexão agrupará a exceção em uma InvocationTargetException.


Isto irá imprimir a linha exata do código no método específico, que quando invocado, levantou a exceção:

try {

    // try code
    ..
    m.invoke(testObject);
    ..

} catch (InvocationTargetException e) {

    // Answer:
    e.getCause().printStackTrace();
} catch (Exception e) {

    // generic exception handling
    e.printStackTrace();
}

Essa InvocationTargetException provavelmente está encerrando sua ArrayIndexOutOfBoundsException . Não há como dizer antecipadamente ao usar a reflexão o que esse método pode lançar - portanto, em vez de usar uma abordagem throws Exception , todas as exceções estão sendo capturadas e encerradas em InvocationTargetException .


Eu tive um erro java.lang.reflect.InvocationTargetException de uma instrução chamando um objeto logger em uma class externa dentro de um bloco try / catch em minha class .

Percorrendo o código no depurador do Eclipse e passando o mouse sobre a instrução logger, vi que o object logger era null (algumas constantes externas precisavam ser instanciadas no topo da minha class ).


Eu estava enfrentando o mesmo problema. Eu usei e.getCause (). GetCause (), então eu achei que era por causa dos parâmetros errados que eu estava passando. Houve nullPointerException em buscar o valor de um dos parâmetros. Espero que isso ajude você.


Você adicionou um nível extra de abstração chamando o método com reflexão. A camada de reflexão envolve qualquer exceção em uma InvocationTargetException , que permite diferenciar entre uma exceção causada por uma falha na reflexão (talvez sua lista de argumentos não seja válida, por exemplo) e uma falha no método chamado.

Apenas desembrulhe a causa dentro da InvocationTargetException e você chegará ao original.


Você pode comparar com a exceção original Classe usando o método getCause () desta forma:

try{
  ...
} catch(Exception e){
   if(e.getCause().getClass().equals(AssertionError.class)){
      // handle your exception  1
   } else {
      // handle the rest of the world exception 
   }
} 

De fato, as exceções verificadas, por um lado, aumentam a robustez e a correção de seu programa (você é forçado a fazer declarações corretas de suas interfaces - as exceções que um método lança são basicamente um tipo de retorno especial). Por outro lado, você enfrenta o problema de que, desde que as exceções "borbulham", muitas vezes você precisa alterar vários métodos (todos os chamadores, chamadores dos chamadores, etc.) ao alterar as exceções. método lança.

Exceções verificadas em Java não resolvem o último problema; C # e VB.NET jogam fora o bebê com a água do banho.

Uma boa abordagem que toma o caminho do meio é descrita neste documento OOPSLA 2005 (ou o relatório técnico relacionado ).

Em suma, permite que você diga:, o method g(x) throws like f(x)que significa que g lança todas as exceções f. Voila, verificou exceções sem o problema de alterações em cascata.

Embora seja um trabalho acadêmico, eu o encorajaria a ler (partes de), já que explica bem quais são os benefícios e desvantagens das exceções verificadas.







java exception reflection invoke