3 層の app-frontend ドメインとデータ アクセスがあるとします。コールスタックの上位にある例外をキャッチするのは良い考えだと読んだことがあります...したがって、データアクセス例外が発生した場合、ドメインレイヤーは単にfinallyを実行します。
試す{
}finally{ //クリーンアップ }
そして、データ アクセス例外をフロントエンド レイヤーに浸透させます。これは、フロントエンドのレイヤーが内部を処理するようにすることで、レイヤリングを壊しませんか? 各レイヤーは、呼び出し元のレイヤーに処理できない例外をハンドラーまたはラップしてスローする必要があると思います...何か考えはありますか?
これまでのところ、多くの良いフィードバックがあります。
ルール＃1。実際に処理する例外のみをキャッチします。ハンドルとは、クライアントの要求が継続できるように処理することを意味します。情報をログに記録するのに十分な時間 (これを悪用しないでください。通常はスタックで十分な情報です)、またはより簡単に伝播する別のエラー (ala ランタイムベース) に変換するのに十分な長さで物事をキャッチできます。しかし、それを処理できない場合は、わざわざ捕まえないでください。それは役に立たず混乱を招く余分なコードです。ログを取ったり変換したりしても、結局は再スローされます。
ほとんどの場合、例外を処理できないことに注意してください。本当に。多くの人はこれを理解できていません。しかし現実には、ディスクの読み取りまたは書き込み中に IOException が発生すると、ゲーム オーバーになります。ユーザーのその要求を完了することはできません。ネットワークが不安定でデータベースと通信できない場合も同様です。
ルール＃2。処理できない例外が発生した場合にできる唯一のことは、ユーザーにとって役立つような方法で失敗を試みることです。これは、後で分析するためにログに記録し (元のスタック/原因を含む)、ユーザーにできるだけ役立つものを報告することを意味します。システムが一貫した状態に保たれるように、必要なものはすべてクリーンアップします。
このエンド ユーザーとのコミュニケーションは非常に高いレベルで行われるため、通常はそのレベルでキャッチする必要があります。ほとんどの場合、例外処理の開始点と、ログ記録およびユーザーへのレポートのために例外をキャッチする最上位レベルの間の例外処理には、ほとんど価値がないことがわかります。私はしばしば RuntimeException の形式に変換しますが、これは層を介した伝播を容易にするためにのみ行われます。
最大かつ最も重要なことは、通常は例外を処理できないことを認識することです。そのため、それらのために記述するコードはできるだけ単純にする必要があります。
ここには 3 つの連動する問題があります。
まず、例外を常に再ラップすることはできますが、それはどのような価値を提供するのでしょうか? 元の例外の周りにさらにレイヤーを作成しているだけです。例外に関する追加情報を提供できる場合、または最初の例外が別の例外を引き起こした場合にのみ、例外をラップします。
第二に、例外の考え方は、関数が正常に完了できないことに応答することです。問題を処理するのが最も理にかなっている場所で例外をキャッチする必要があります。コードに「別の代替手段」がある場合、その時点で例外をトラップする必要があります。それ以外の場合は、ユーザーまたは開発者が解決できるようにログに記録してください。
3 つ目は、try/finally ブロックです。これらは、例外によってリソースがオープンまたは割り当て済みの状態でハングアウトする場合に役立ちます。私は常に try/finally を使用して、開いたままになる可能性のあるリソースをクリーンアップします (私のお気に入りは、大量のメモリを消費する java.sql の Statement/ResultSet です)。非常に優れたプログラマーは、大量のメモリ リークやリソースの制約を発生させずに適切に回復する方法として、コードにこれを数多く取り入れています。
レイヤリングが、これで壊れるほど純粋なアイデアだとは思いません。
ラッピングと再スローもあまり価値がありません。
サービス層で例外を処理することの何が問題になっていますか? それが最後の防衛線であるはずです。この設計により、サービスは例外を一度だけログに記録し、ユーザー フレンドリーなメッセージを UI に送信して表示できます。
一般的には、コール スタックの上位で例外をキャッチする必要がありますが、それが意味をなすところまでしかキャッチできません。データ レベルで例外を処理してログに記録し、フロントエンドにメッセージを返すだけでよい場合は、物事が単純かつ柔軟に保たれます。
個人的には、試して最終的に行う必要がある場合は、呼び出し元に渡すのではなく、状況をキャッチして何かをしたいと思います。優れたデザイン ルールには常に例外があることに注意してください (通常は、KISS などの別のルール)。