意見を求めたかっただけです。すべての例外をインターセプトし、それらをアプリケーション固有の例外に変換するインターセプタークラスを用意するのは良い考えだと思いますか?基本的に、例外処理(および他には何もありません)は、クラスから別のクラスに移動されます。
これについて賛否両論を教えていただけますか?
ありがとうございました。
はい、これは合理的な考えです。org.springframework.jdbc.support.SQLExceptionTranslator
例としてSpringを見てください。これは、イライラするチェック済みの例外をチェックされていない例外に変換するのに特に適しています。
通常の欠点は複雑さが増すことです。したがって、アプリケーション固有の例外がいくつあるかによって異なります。
本当に悪い考えだと思います。ある条件に対してIllegalArgumentExceptionをスローすることを文書化するインターフェイスを使用する場合、この条件が満たされると、アプリケーション固有の例外ではなく、IllegalArgumentExceptionが発生することが予想されます。
バグがあり、NullPointerExceptionがスローされる場合は、問題が何でどこにあるかを通知しないアプリケーション固有の例外に含めるのではなく、問題を直接識別するNullPointerExceptionを取得することをお勧めします。
ここで、クラスがAOPの意味でインターセプターではなく、別のオブジェクトまたはAPIのラッパー(たとえば、spring-jdbcはJDBCのラッパー)であり、チェックされた例外のみを意味のあるアプリケーション固有の例外に変換する場合ちなみに、問題はありません。
場合によっては、複雑さを軽減するために使用できるように思えます。データベースが埋め込まれたアプリがあります。欠落しているレコード、SQL 例外、あらゆる種類のものを取得できましたが、いずれもユーザーに報告したくありませんでした。一部のUIクラスには、呼び出す別のメソッドを呼び出すメソッドがあり、どこかでコードがこれらのいずれかに遭遇し、それを戻し始めます。アプリケーション設計に固有の適切なレベルで、それをトラップし、おそらくログに記録し、アプリケーション固有の例外にラップします。その仕事は、ユーザーに正しいことをさせるメッセージを生成することです。何かがおかしいことを彼に通知する以外に。アプリ固有の例外は、結果のメッセージを表示するユーザーに合わせて調整されており、一連の「下位レベル」に応答して生成できます。