私はSOで、「チェックされた例外に対するケース」というタイトルのこのすばらしい議論をフォローしていますが、RuntimeExceptionを正確に使用する場所と、通常の例外およびそのサブクラスとの違いを理解できません。グーグルは私に複雑な答えを与えました。つまり、プログラミングロジックエラーを処理するために使用する必要があり、switch-case構造のデフォルトブロックなど、通常は例外が発生しない場合にスローする必要があります。
ここでRuntimeExceptionについて詳しく説明してください。ありがとう。
RuntimeExceptionを正確に使用する必要がある場所を追跡できません
それはおそらくあなたが議論を見ているからです、すなわち人々はまさにこの点について意見が分かれています。
また、通常の例外およびそのサブクラスとの違い。
非常に単純：のすべてのサブクラス（およびそのサブクラスExceptionを除く）がチェックされます。つまり、コンパイラーは、キャッチしたコードを拒否するか、メソッドシグネチャで宣言します。ただし、のサブクラスはチェックされていません。RuntimeExceptionRuntimeException
グーグルは私に複雑な答えを与えました。つまり、プログラミングロジックエラーを処理するために使用する必要があり、switch-case構造のデフォルトブロックなど、通常は例外が発生しない場合にスローする必要があります。
これは従来の知識であり、プログラムが有効に処理できるすべてのものについて、チェックされた例外を使用する必要があります。そうすると、コンパイラが例外を処理するように強制するからです。逆に、プログラムは通常、プログラマーのエラーをうまく処理できないため、チェックする必要はありません。これは、Java標準APIが使用する方法RuntimeExceptionです。
あなたがリンクした議論は、チェックされた例外が悪いコードにつながるので使用されるべきではないと考える何人かの人々（これは私を含む）の見解によって引き起こされます。コンパイラで例外チェックを無効にすることはできないため、これを行う唯一の方法は、とそのサブクラスのみを使用することです。 RuntimeException
IMOがこの見解をサポートしているという1つの観察は、「プログラマーエラーにのみ未チェックの例外を使用する」という従来の知識は、実際には主に逆推論の合理化であるということです。コンパイラーがプログラマーに対処するように強制してはならないコードの安全性の理由はありません。エラー。ただし、のようなものはほとんどどこNullPointerExceptionにArrayIndexOutOfBoundsExceptionでも出現する可能性があり、それらをチェックした場合、誰もJavaでプログラミングしたいとは思わないでしょう。したがって、言語設計者は、それらの例外を作成し、チェックを外さなければなりませんでした。これを説明するために、彼らは「チェックされていない例外はプログラマーのエラーのためのものです」という話を思いついた。
効果的なJava2ndEdition、アイテム58からの引用：回復可能な条件にはチェック済みの例外を使用し、プログラミングエラーには実行時の例外を使用する
Javaプログラミング言語は、チェック例外、ランタイム例外、およびエラーの3種類のスロー可能オブジェクトを提供します。プログラマーの間では、各種類のスローアブルをいつ使用するのが適切かについて混乱があります。決定は必ずしも明確ではありませんが、強力なガイダンスを提供するいくつかの一般的なルールがあります。
チェックされた例外を使用するか、チェックされていない例外を使用するかを決定する際の基本的なルールは次のとおりです。
- 呼び出し元が回復することが合理的に期待できる条件には、チェックされた例外を使用します。チェックされた例外をスローすることにより、呼び出し元に句内の例外を処理する
catchか、それを外部に伝播するように強制します。したがって、メソッドがスローするように宣言されているチェック済みの各例外は、関連する条件がメソッドの呼び出しの結果である可能性があることをAPIユーザーに示す強力な指標です。- 実行時例外を使用して、プログラミングエラーを示します。実行時例外の大部分は、前提条件違反を示しています。前提条件違反とは、APIのクライアントが、API仕様で指定されたコントラクトを順守できなかったことを意味します。
次に例を示します。
FileNotFoundExceptionチェックされた例外です。nullファイル名として文字列を指定する場合は、 NullPointerException（またはおそらくIllegalArgumentException-別の論争の的となる議論）がスローされます。APIのクライアントは、有効な文字列値を提供することになっています。nullそうではありません。APIに関する限り、これはプログラマーのエラーであり、簡単に防ぐことができました。これらの例外は両方とも実行時の例外です。項目59：チェックされた例外の不必要な使用を避けることも追加のガイダンスを提供します：
チェックされた例外は、Javaプログラミング言語のすばらしい機能です。戻りコードとは異なり、プログラマーは例外的な条件に対処する必要があり、信頼性が大幅に向上します。とはいえ、チェックされた例外を使いすぎると、APIの使い勝手が大幅に低下する可能性があります。メソッドが1つ以上のチェック済み例外をスローする場合、メソッドを呼び出すコードは1つ以上の
catchブロックで例外を処理するか、例外を宣言してthrows外部に伝播させる必要があります。いずれにせよ、それはプログラマーに取るに足らない負担をかけます。次の場合、負担は正当化されます。
- APIを適切に使用しても、例外的な状態を防ぐことはできません。
- APIを使用するプログラマーは、例外に直面すると、いくつかの有用なアクションを実行できます。
これらの条件の両方が当てはまらない限り、チェックされていない例外がより適切です。
そこで、 Effective Java2ndEditionからの推奨事項の簡単な要約を次に示します。
チェックされていない例外は、RuntimeExceptionとそのサブクラス、およびそのサブクラスとして定義されErrorます。throwsメソッドの句で宣言する必要はありません。