例外をラップする

3. ラッピング例外

チェック例外は理論的にはクールに見えましたが、実際には大きなフラストレーションとなることが判明しました。

プロジェクトに非常に人気のあるメソッドがあるとします。これはプログラム内の何百もの場所から呼び出されます。そして、新しいチェック例外をそれに追加することにしました。そして、このチェック例外は非常に重要で特別なので、それがキャッチされた場合に何をすべきかをメソッドだけが知っている可能性がありますmain()。

つまり、非常に人気のあるメソッドを呼び出すすべてのメソッドの句にチェック例外を追加する必要がありますthrows。同様に、throwsそれらのメソッドを呼び出すすべてのメソッドの句でも同様です。また、それらのメソッドを呼び出すメソッドについても同様です。

その結果、throwsプロジェクト内のメソッドの半分の句に新しいチェック例外が発生します。そしてもちろん、プロジェクトはテストの対象になっていますが、テストはコンパイルされません。そして今度は、テスト内の throws 句も編集する必要があります。

そして、すべてのコード (数百のファイルのすべての変更) を他のプログラマーがレビューする必要があります。そしてこの時点で、なぜプロジェクトにこれほど多くの血なまぐさい変更を加えたのかを自問します。数日の作業と壊れたテスト - すべては 1 つのチェック例外を追加するためでしょうか?

そしてもちろん、継承とメソッドのオーバーライドに関連する問題はまだ残っています。チェック例外によって生じる問題は、利点よりもはるかに大きいです。肝心なのは、今ではそれらを愛する人も使用する人もほとんどいないということです。

ただし、これらのチェック例外を含むコード (標準 Java ライブラリ コードを含む) が依然として多数存在します。彼らに対して何をすべきでしょうか？私たちはそれらを無視することはできませんし、どのように対処すればよいのかわかりません。

Java プログラマーは、チェックされた例外を でラップすることを提案しましたRuntimeException。つまり、すべてのチェック済み例外をキャッチしてから、非チェック例外 (たとえば、RuntimeException) を作成し、代わりにそれらをスローします。これを実行すると次のようになります。

try
{
   // Code where a checked exception might occur
}
catch(Exception exp)
{
   throw new RuntimeException(exp);
}

これはあまりきれいな解決策ではありませんが、ここには何も犯罪的なものはありません。例外は単に .html の中に詰め込まれているだけですRuntimeException。

必要に応じて、そこから簡単に取得できます。例：

try
{
   // Code where we wrap the checked exception
   // in a RuntimeException
}
catch(RuntimeException e)
{
   Throwable cause = e.getCause();
   if (cause instanceof Exception)
   {
      Exception exp = (Exception) cause;
      // Exception handling code goes here
   }
}