java - Javaでランタイム例外が「チェックされていない」のはなぜですか？

Question

ランタイム例外を（チェックされている場合とは対照的に）チェックされていないことが理にかなっているのはなぜですか？

Answer 1

そうしなかった場合は、配列要素にアクセスするたびにtry / catchブロックが必要になり、除算操作やその他の多くの一般的なシナリオが実行されます。

別の言い方をすれば、このコードを想像してみてください。

Map map = ...
int i = ...
(int[])map.get("foo")[3] = 2334 / i;

、、、、そして頭のてっぺんからチェックする必要がありClassCastExceptionます。ArrayIndexOutofBoundsExceptionArithmeticExceptionUnsupportedOperationExceptionNullPointerException

Javaの場合、問題はチェックされていない例外ではありません。チェックされた例外は非常に物議を醸す主題です。これは主にJavaでの実験であり、実際には機能しないと言う人もいますが、彼らは良いと主張する人がたくさんいます。

ただし、チェックされていない例外が悪いと主張する人は誰もいません。

Answer 2

Javaの2種類の例外（チェックされているものとチェックされていないもの）の考え方は、チェックされた例外は、合理的に発生すると予想されるエラー条件に使用され、チェックされていない例外は、予期しないエラー条件に使用される必要があるというものです。

たとえば、ファイルが見つからない場合は、を取得しFileNotFoundException、プログラムがそのような条件を処理できることを期待するのが妥当です。チェックされていない例外は、発生してはならない問題にのみ使用する必要があります。つまり、このような問題が発生した場合、プログラムにバグがあることを意味します。たとえば、NullPointerExceptionプログラムが変数を逆参照しようとしていることを意味しますnull。これはバグである可能性が最も高いです。

Javaコンパイラは、プログラマにチェックされた例外の処理を強制します。これにより、プログラミング言語がより安全になります。つまり、プログラマーはエラー状態について考える必要があり、プログラムがより堅牢になるはずです。

チェックされていない例外はとにかく発生することは想定されていないため、コンパイラはチェックされていない例外をチェックしません。発生した場合、プログラムが実行時に合理的に実行できることは何もありません。プログラマーはバグを解決する必要があります。

Javaのこの機能にはいくつかの批判があり、チェックされた例外を失敗した実験と呼ぶ人もいれば、チェックされた例外をJavaから削除することを提案する人もいます。

Answer 3

これは単に、コンパイラが例外を探すように強制しないことを意味しますが、実行時にそれをスローすることはできます。1つの利点として、これにより、インターフェイスを変更せずにクラスから新しい例外をスローして、呼び出し元にコードを変更させることができます。