まあ、何が原因なのか理解し、読もうとしたのですが、どうしても理解できません:
私のコードのどこかにこれがあります:
try{
..
m.invoke(testObject);
..
} catch(AssertionError e){
...
} catch(Exception e){
..
}
あるメソッドを呼び出そうとすると
InvocationTargetExceptionがスローされます。 実際にどのメソッドが呼び出されるかは分かっているので、このメソッドのコードに直行し、
ArrayIndexOutOfBoundsExceptionをスローすると思われる行にtry-catchブロックを追加したところ、予想通り本当に
ArrayIndexOutOfBoundsExceptionがスローされた。しかし、上に進むと 上のコードでは
catch(Exception e)が
InvocationTargetExceptionになっている。 eは
InvocationTargetExceptionであり、
ArrayIndexOutOfBoundsException`ではない。
になります。
何がこのような動作を引き起こすのでしょうか?
あなたは、リフレクションを使ってメソッドを呼び出すことで、抽象化のレベルを追加しました。リフレクションレイヤーはどんな例外も InvocationTargetException
で包みます。これにより、リフレクション呼び出しの失敗 (例えば、引数リストが有効でなかったなど) によって引き起こされた例外と、呼び出されたメソッド内の失敗の違いを見分けることができます。
InvocationTargetException`の中の原因をアンラップするだけで、元の例外にたどり着くことができる。
Method.invoke()のJavadocから。
をスローします: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.get Cause()メソッドと 前述の「レガシー法。"。