java.lang.reflect.InvocationTargetExceptionの原因は何ですか？

まあ、私はそれを引き起こす可能性があるものを理解して読んでみましたが、それを得ることができません：

私のコードのどこかにこれがあります：

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

それは、あるメソッドを呼び出そうとするInvocationTargetExceptionと、他の予期される例外（具体的にはArrayIndexOutOfBoundsException）の代わりにスロー されるということです。呼び出されるメソッドを実際に知っているので、このメソッドコードに直接進み、スローするはずの行にtry-catchブロックを追加しましたArrayIndexOutOfBoundsExceptionがArrayIndexOutOfBoundsException、期待どおりに実際にスロー されました。それでも上に行くと、どういうわけかInvocationTargetException、上記のコードに変更され、catch(Exception e) eは 予想どおりではInvocationTargetExceptionありませんArrayIndexOutOfBoundsException。

何がそのような動作を引き起こす可能性がありますか、またはどのようにしてそのようなことを確認できますか？

リフレクションを使用してメソッドを呼び出すことにより、抽象化のレベルを追加しました。リフレクションレイヤーは例外をでラップInvocationTargetExceptionします。これにより、リフレクション呼び出しの失敗によって実際に引き起こされた例外（たとえば、引数リストが無効であった可能性があります）と呼び出されたメソッド内の失敗の違いを知ることができます。

内で原因を解明するだけで、元の原因に戻ることがInvocationTargetExceptionできます。

例外は次の場合にスローされます

InvocationTargetException-基本となるメソッドが例外をスローした場合。

したがって、リフレクションAPIで呼び出されたメソッドが例外（たとえば、ランタイム例外）をスローした場合、リフレクションAPIは例外をにラップしますInvocationTargetException。

のgetCause()メソッドを使用してInvocationTargetException、元の例外を取得します。

Method.invoke（）のJavadocから

スロー：InvocationTargetException-基本となるメソッドが例外をスローした場合。

この例外は、呼び出されたメソッドが例外をスローした場合にスローされます。

それはInvocationTargetExceptionおそらくあなたをラップしていますArrayIndexOutOfBoundsException。リフレクションを使用する場合、そのメソッドがスローできるものを事前に伝える必要はありません。そのため、throws Exceptionアプローチを使用する代わりに、すべての例外がキャッチされてにラップされInvocationTargetExceptionます。

これは、呼び出されたときに例外を発生させた特定のメソッドの正確なコード行を出力します。

try {

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

} catch (InvocationTargetException e) {

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

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

これは、

InvocationTargetExceptionは、呼び出されたメソッドまたはコンストラクターによってスローされた例外をラップするチェック例外です。リリース1.4以降、この例外は汎用の例外チェーンメカ​​ニズムに準拠するように改良されました。構築時に提供され、getTargetException（）メソッドを介してアクセスされる「ターゲット例外」が原因として認識され、Throwable.getCause（）メソッドと前述の「レガシーメソッド」を介してアクセスできます。

次のようにgetCause（）メソッドを使用して、元の例外クラスと比較できます。

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

私の/ ブロック内java.lang.reflect.InvocationTargetExceptionの外部のロガーオブジェクトを呼び出すステートメントからエラーが発生しましたclasstrycatchclass。

Eclipseデバッガーでコードをステップ実行して、ロガーobjectが表示されているロガーステートメントの上にマウスを移動しますnull（いくつかの外部定数は、私の最上部でインスタンス化する必要がありましたclass）。

この例外は、基になるメソッド（Reflectionを使用して呼び出されたメソッド）が例外をスローした場合にスローされます。

したがって、リフレクションAPIによって呼び出されたメソッドが例外（たとえば、ランタイム例外）をスローした場合、リフレクションAPIは例外をInvocationTargetExceptionにラップします。

私も同じ問題に直面していました。e.getCause（）。getCause（）を使用したところ、渡したパラメーターが間違っていたことが原因であることがわかりました。パラメータの1つの値をフェッチするときにnullPointerExceptionがありました。これがお役に立てば幸いです。

1. Eclipseナビゲーターモードからすべてのjarファイルをリストする
2. すべてのjarファイルがバイナリモードであることを確認します

Clean-> Run xDoclet-> Run xPackagingを実行した後、エラーは消えました。

私のワークスペースでは、Eclipseで。