9

javadocsに従って、null にInvocationTargetException.getCause()することができます。

この例外の原因 (スローされたターゲット例外。null の場合もあります) を返します。

ただし、ドキュメントには、既存の例外をラップすることも記載されています。

InvocationTargetException は、呼び出されたメソッドまたはコンストラクターによってスローされた例外をラップするチェック済み例外です。

だから私にInvocationTargetException.getCause() は決してそうではないように思えますnull。

何か不足していますか？

アップデート

はい、私は何かを逃しました - のデフォルトのコンストラクターはnullになるInvocationTargetExceptionでしょう。getCause()

私が今抱えている問題は、なぜこのクラスにデフォルトのコンストラクターを提供するのかということです。null の原因で例外をスローする必要があるユースケースはありますか?

4

4 に答える 4

1

InvocationTargetExceptionReflectiveOperationExceptionどの州を拡張するか

コア リフレクションのリフレクション操作によってスローされる例外の一般的なスーパークラス。

リフレクションを使用してメソッド (またはコンストラクター) を呼び出す場合。

Method method = ...
method.invoke(instance, ...);

メソッドが例外をスローした場合、それは のtargetフィールドに格納されますInvocationTargetException。これは、ほとんどのリフレクションの場合に発生します。

空のコンストラクターがあるという事実は、他の場合には別の方法で使用される可能性があると私に信じさせます。

JDK7

private Throwable target;

/**
 * Constructs an {@code InvocationTargetException} with
 * {@code null} as the target exception.
 */
protected InvocationTargetException() {
    super((Throwable)null);  // Disallow initCause
}
于 2013-07-16T18:47:35.787 に答える
0

まず、コンストラクターnullを介して許可されるのは原因だけではないことに注意してください。to の値を指定してコンストラクタをprotected呼び出すこともできます。いいえ発生しません...publictargetnullNullPointerException

そうは言っても、デザイナーが単に滑っただけではないようです。

次のように、設計者がリフレクションを介してクラスをインスタンス化できるようにしたかった可能性があります。

Constructor ctor = // ... some code to get the no-arg constructor that I spared here
ctor.setAccessible(true); // it's protected constructor...
InvocationTargetException e = (InvocationTargetException) ctor.newInstance();

そのようにして、util メソッドはInvocationTargetExceptionインスタンスを作成し、特定の原因を追加するクライアント コードに渡すことができます。

于 2013-07-16T19:57:05.797 に答える