ネストされた例外を選択的に「キャッチ」する、これほど洗練された方法はありません。この種のネストされた例外を大量にキャッチした場合、コードをリファクタリングして共通のユーティリティ メソッドにすることができると思います。しかし、それでもエレガントでも効率的でもありません。
エレガントな解決策は、例外の入れ子をなくすことです。そもそも例外を連鎖させないか、(選択的に) ラップを解除して、ネストされた例外をスタックのさらに上に再スローします。
例外は、次の 3 つの理由で入れ子になる傾向があります。
元の例外の詳細がアプリケーションのエラー回復に役立つ可能性は低いと判断しましたが、診断目的でそれらを保存したいと考えています。
特定のチェック済み例外を許可しない API メソッドを実装していますが、コードがその例外をスローすることは避けられません。一般的な回避策は、チェックされていない例外内にチェックされた例外を「密輸」することです。
あなたは怠け者で、関連のないさまざまな例外のセットを 1 つの例外に変えて、メソッド シグネチャに多数のチェック済み例外が含まれないようにしています1。
最初のケースで、ラップされた例外を区別する必要がある場合、最初の仮定は間違っていました。最善の解決策は、ネストを取り除くことができるようにメソッド シグネチャを変更することです。
2 番目のケースでは、制御が問題のある API メソッドを通過したらすぐに例外をラップ解除する必要があります。
3 番目のケースでは、例外処理戦略を再考する必要があります。すなわち、適切に行う2。
1 - 実際、Java 7 で複数例外の catch 構文が導入されたため、これを行う半正当な理由の 1 つがなくなりました。
2 - API メソッドを に変更しないでくださいthrows Exception
。それは事態を悪化させるだけです。Exception
メソッドを呼び出すたびに、「処理」または伝播する必要があります。それは癌です...