以下はあくまで私の個人的な実践であり、参考としてのみご利用ください。

Controller レイヤー:
AOP または Filter の介入なしで、 メソッド内で生成されたすべての例外 は

DAO レイヤー:
このレイヤーの例外はほとんどが SQL 例外であり、通常、Service 処理のために

Service レイヤー:
例外が呼び出し元の介入を必要としないとみなされる場合は、サービス内で処理されます。そうでない場合は、処理のために呼び出し元にスローされます (実際には、これは転送です)責任がある...);

キャッチして別の Exception をスローする状況は 1 つだけあります。これは、例外 A をキャッチしてから例外 B をスローすることです。これは、通常、例外を均一に処理するために AOP を使用することと組み合わせられます。例: catch A、B、および C の例外はすべて、AOP の D 例外ハンドラーによって処理されます。

個人的には、例外をキャッチする原則は、コードに予期される例外に対するビジネス処理が必要な場合にのみ例外をキャッチする必要がある、たとえば SQL エラーが発生した場合、トランザクションをロールバックする必要がある、ということだと思います。その他の例外については、基本的に例外をキャッチする必要はありません。レイヤー ビジネスは例外を一律に処理できます。

いくつかの個人的な提案:

(1) チェックされた例外は RuntimeException に変換されます。これをスローすることは通常バグとみなされます。
(2) カスタム例外 (ビジネス例外) は RuntimeException から継承します。カスタム例外を設計する場合は、例外のスローを考慮する必要があります。終了時には、ログ情報を通じて異常なシナリオを迅速に再現できます。
(3) 例外をスローするかどうかについては、一般的に、呼び出し元がビジネス例外が発生する可能性があり、それを処理できることを知っている必要がある場合は、例外をスローします。呼び出し元が例外を処理できない場合、例外はキャッチされます。要するに、「責任を転嫁」しないでください。
(4) この種のコードは、例外が発生したときに問題を迅速に特定することが困難になるため、強くお勧めしません。 catch Exception

Dao 層は例外を直接上向きにスローすることをお勧めします (通常はデータベース ランタイム例外)。 Service 層は他のアプリケーションに公開され、アプリケーションに渡す必要があるビジネス情報が多数あります。上位層の呼び出し元には次の 2 つの方法があります

1. ビジネス例外をスローすることで、特定のビジネス例外情報/システム例外情報を呼び出し元に通知します(システム例外。上位層は注意を払わない可能性があります)

2. Service は、例外が発生しないことを保証し、Result を上位層に返します。Result に含まれる情報は、呼び出しが成功したかどうか、失敗した場合は次のとおりです。ビジネス情報

したがって、すべてのレベルで例外をキャッチする必要はありません。例外を処理したい場合は、(単一のアプリケーションであっても、将来のサービスであっても) それを処理するだけです。サービスは選択したチームによって異なります Service