2

メソッドがあると想像してください：

public static void funcA() {...}

public static void funcB() 
{
    byteBuffer.wrap(someByteArray, 0, someByteArra.length);
}

Java API の場合:

public static ByteBuffer wrap(byte[]array, int offset, int length)
{
    try {
        return new HeapByteBuffer(array, offset, length);
    } catch (IllegalArgumentException x) {
        throw new IndexOutOfBoundsException();
    }
}

関数チェーン: funcB() -> ByteBuffer.wrap()

私の質問は、例外をスローするこの Java api メソッドの周りで funcB が try-catch ブロックを実行する必要がないのはなぜですか。funcB は、try-catch ブロックなしで正常にコンパイルされます。答えは、Java APIメソッドが例外をスローするが、「IndexOutOfBoundsExceptionをスローする」と宣言されていないという事実に関係していると思います

関数チェーン: funcA() -> funcB() -> ByteBuffer.wrap(...)

次の質問は、funcB を「funcB() が IndexOutOfBoundsException をスローする」に変更するとき、なぜfuncAが funcB のスローされた例外をキャッチする必要がないのかということです。コンパイラは深く掘り下げて、ByteBuffer.wrap(...) が「wrap() が IndexOutOfBoundsException をスローする」と宣言されていないことを認識するので、すべての呼び出し元は実際にはサブ呼び出し元 (この場合は funcB) でさえ実際に何かをキャッチする必要はありません。 「funcB が IndexOutOfBoundsException をスローする」と宣言されていますか?

わかりにくかったり、わかりにくかったらすみません。

助けてください。

jbu

4

2 に答える 2

9

IndexOutofBoundsExceptionはRuntimeExceptionを拡張します。これはランタイム例外であり、チェックする必要はありません。

チェックされていない例外を参照してください- 論争。

于 2009-04-03T19:49:47.750 に答える
4

例外階層の最上位は java.lang.Throwable です。これはチェック例外です (コンパイラーは、例外をキャッチするか、スローすることを宣言するように強制します)。

Throwable の下には、やはりチェックされた例外である Exception と、チェックされていない例外である Error があります (コンパイラはそれについて警告しません)。

Exception の下には、RuntimeException もチェックされない例外があります。

Java の設計者が意図した例外の使用方法は次のとおりです。

  • 例外、うまくいかないもの
  • エラー、問題が発生する可能性があり、プログラムが回復できない低レベルのもの
  • RuntimeException、プログラマ エラー (配列の末尾を超える、null でメソッドを呼び出すなど)。

チェックされていない例外をキャッチする必要がないという考え方は、処理できない (VM エラー) か、適切にデバッグされたプログラムに存在しない (プログラマーのミス) 障害 (VM レベルまたはプログラマー) を示しているということです。

これに関する Java の設計者の意図に誰もが同意するわけではなく、RuntimeException を使用して、プログラマーのミス以外のことを意味することを選択しました。

于 2009-04-03T20:18:27.527 に答える