私の会社では、自分で設計し、インターフェイスとして指定するサーバーセントラルサービスを含むWebアプリケーションを構築しています。つまり、インターフェイスはアプリケーション固有であり、その後、時間の経過とともに変更される可能性があるサードパーティのライブラリを使用して実装されます。例外に関しては、サービスによってスローされる例外は、実装固有の例外ではなく、独自のアプリケーション固有の例外でなければならないことに気付きました。
さて、私は私たちの例外がどのように構造化され、相互に関連付けられるべきか疑問に思っています。
まず、一般的な例外について考えますMyAppException。この例外は、予期しない問題が発生したことを示しています。ユーザーにメッセージを表示して、問題が発生し、現在作業中であることを伝えることが最善の方法です。エラーは、データベースがクラッシュしたか、何か類似したものである可能性があります。この例外は、データベースを操作するすべてのメソッドからほとんどスローされます。
次に、例外を検討しますMyAppDuplicateException。この例外は、ユーザーがすでに存在するデータベースに何かを保存しようとしたことを示します。ここでは、より具体的なエラーメッセージを表示できます。この例外は、データベース行を挿入または更新するメソッドからのみスローされます。
アプリケーションにはMyAppDuplicateException、その他の予期しないエラー状況と同様のその他の例外を含めることもできます。例MyAppNotFoundExceptionなど...
今私の質問に：
- 他の例外は拡張する必要があります
MyAppExceptionか？実はその理由はわかりません。色んなところで見ただけで、目的があるのかなと思います。私が見るようにこれの欠点は、try / catch-statementがこの場合の特定の例外を気にする必要がないことです。それは単にトップの例外をキャッチすることができ、そのため、特定の例外を持っていることのほとんどのポイントであった特定のエラーを処理する必要はありません。 - 他の例外がない場合ではない拡張する
MyAppException、すべきMyAppExceptionことjava.lang.RuntimeException？これは、コードを実行してそれをキャッチする必要はありません。例外のポイントは、何か不明なことが発生し、実行中のコードがそれを処理できるように期待されていないということだからです。リクエストのエントリポイントのコードには、キャッチMyAppExceptionしてユーザーにメッセージが表示されることを確認するtry / catchステートメントを含めることができます。
編集などの特定の例外をMyAppDuplicateExceptionチェックする必要があるかどうかは問題ではありません。チェックする必要があります。