[解決済み】チェックされた例外とチェックされていない例外を選択する場合

質問内容

Java（またはチェックされた例外を持つ他の言語）で、独自の例外クラスを作成する場合、チェックするかしないかをどのように決定するのでしょうか？

私の直感では、チェックされた例外は呼び出し側が何らかの生産的な方法で回復できる可能性がある場合に呼び出され、チェックされていない例外は回復不可能な場合に呼び出されると思いますが、他の人の考えも聞いてみたいです。

どのように解決するのですか？

チェックされた例外は、それがいつ使用されるべきかを理解している限り、素晴らしいものです。JavaコアAPIはSQLException(そして時にはIOException)についてこのルールに従わないので、とてもひどいことになっています。

チェックされた例外 を使用する必要があります。 予測可能 しかし 防止できない というエラーは 回復のための合理的な .

チェックされていない例外 は、それ以外のものに使用する必要があります。

ほとんどの人がこの意味を誤解しているので、噛み砕いて説明します。

1. 予測はできるが、防ぐことはできない : 呼び出し側は入力パラメータを検証するために全力を尽くしたが、呼び出し側の制御外の何らかの条件によって操作に失敗した。例えば、ファイルを読み込もうとしたが、ファイルが存在するかどうかを確認してから読み込み操作を開始するまでの間に誰かがファイルを削除してしまったとする。Checked exception を宣言することで、呼び出し側にこの失敗を予期するよう伝えることができます。
2. 回復のための合理的な方法 : 呼び出し側に、回復できない例外を予期するよう指示する意味はありません。もしユーザーが存在しないファイルから読み込もうとしたら、呼び出し元は新しいファイル名を入力するように促すことができる。一方、プログラミングのバグ（無効なメソッド引数やバグだらけのメソッド実装）によってメソッドが失敗した場合、アプリケーションは実行の途中で問題を修正することはできません。できることは、問題を記録し、開発者が後でそれを修正するのを待つことです。

投げられている例外が すべて 上記の条件のうち、Unchecked Exceptionを使用する必要があります。

各レベルで再評価する : チェックされた例外をキャッチするメソッドが、エラーを処理する場所として適切でないこともあります。その場合は、自分の呼び出し側にとって何が妥当かを考えましょう。もしその例外が予測可能で、回避不可能で、呼び出し元が回復するのが妥当なものであれば、チェックされた例外を自分で投げるべきでしょう。そうでない場合は、その例外を未チェックの例外でくくるべきです。このルールに従えば、どの階層にいるかによって、チェックされた例外をチェックされていない例外に変換したり、逆にチェックされた例外をチェックされていない例外に変換したりすることに気がつくはずです。

チェックされた例外とチェックされていない例外の両方について。 適切な抽象化レベルを使用する . 例えば、2つの異なる実装（データベースとファイルシステム）を持つコードリポジトリでは、実装固有の詳細を明らかにするために SQLException または IOException . その代わりに、すべての実装にまたがる抽象化で例外をラップする必要があります (例. RepositoryException ).