通常、Exception クラスを拡張するのは、例外をチェックするかチェックしないかを気にしたくないからだと思います。私は正しいですか？
これに関連する別の質問をしました。これが私の質問と得た回答のリンクですhttps://stackoverflow.com/questions/14169866/while-creating-my-own-exception-when-should-i-extend- exception-class-and-when-sh しかし、まだ 1 つの混乱があります。つまり、一般的に Exception クラスを拡張するのは、例外をチェックするかチェックしないかを気にしたくないからだと思います。私は正しいですか？
はい、RuntimeException の代わりに Exception を拡張する唯一の理由は、それをチェックすることです。
チェックされていない例外をスローしたい特別なケースがあるかもしれませんが、ほとんどの場合、例外がスローされた場合に呼び出し元のメソッドが回復できるようにするため、例外をスローするときにそれを行います。チェック例外。また、独自の例外を使用してプログラム内の低レベルの例外をラップし、より疎結合にすることもよくあります。つまり、後で SQL サーバーを別のテクノロジに交換できるように、SQLException をカスタム DatastoreException に変換します。
したがって、Exception を拡張してチェック済みにしますが、例外をやみくもに常に拡張する必要があるとは思いませんが、代わりに、必要な例外が RuntimeException であるかどうかを検討してください。
Spring など、現在使用されているいくつかのフレームワークを見ると、ランタイム例外の使用が推奨されていることがわかります。一般に、特定の例外をキャッチしても呼び出し元にとって意味がない場合は、実行時例外を使用します。呼び出し元はその例外について何もできないためです。したがって、必要に応じて発呼側の裁量で処理するようにしておきます。ただし、RuntimeException クラスではなく Exception クラスを使用する場合、呼び出し元はこれらの例外を処理する必要がありますが、仕様ではこれらの例外はチェック済み例外として分類されているため、処理する必要はありません。