他のJava EEプログラマの例外処理方法についての入力を収集しようとしています。エラー処理（例えば、サーブレットフィルタ）を集中管理しますか？Java EEプロジェクトの例外処理アーキテクチャ
異なるアプリケーション層（永続性、サービスなど）に異なる例外タイプを作成していますか？
例外を飲み込み、チェーンにまったく投げ込まないでください。
例外処理アーキテクチャには他にどのようなパラダイムがありますか？どちらを使用し、なぜですか？
永続性レイヤーは、JPAまたはHibernateを使用して実装されている場合は、すでに独自の例外があります。これは実行時の例外です。
無効な引数が渡されたとき（プレゼンテーションレイヤーによって検証されると想定されるとき）、または回復可能なエラーが発生したときにチェックされた例外（例：データベースに選択された名前が既に存在します）。
プレゼンテーション層の各コントローラは、呼び出すビジネスサービスによってスローされたチェックされた例外を処理し、意味のあるエラーメッセージを表示し、エラーからユーザーを回復させる（例：フォームを再表示し、
プレゼンテーション層、ビジネス層、またはパーシスタンス層から来る他のすべてのランタイム例外は、1つまたは複数のグローバル例外ハンドラ（ほとんどのUIフレームワークでサポートされています）によって処理されます。 （例： "予期しないエラーが発生しました"、 "他のユーザーが変更しようとしたオブジェクトを変更または削除しました"）。
嚥下の例外は、実際には適切な処置であるごくわずかな場合にのみ受け入れられます。
Javaのチェック例外は、実際に発生した場所の近くでエラーを処理する方法を検討することを強制します。例外をDomainException（またはその適切なサブクラス）にラップし、実際にそれを処理して正常に回復できる場所に呼び出し側のチェーンを送信することは、完全に受け入れられることに注意してください。
ほとんどの場合、すべての例外をキャッチして処理できるように、一番上のtry-catchがあります。これは、（あなたにとって意味のある例外にラップすることによって）多くのロジックを提供することが非常に重要であるため、このハンドラがそれに応じて動作することができる理由です。
既知の場合、適切な処置を講じることができます。
不明な場合は、システムが予期しない状態になっているため、非常に大声で失敗することがあります。可能な限りログを作成します。そうしないと再現できない可能性があります。適切な状態を入力してください（終了、追加のサービスを拒否する、またはモデルに応じて続行する）。
例外を飲み込むことを強くお勧めします。これは、問題の原因を調査するために多くの時間を無駄にする最善の方法です。私は結局、空のcatch節に隠れた例外を見つけたときにとても多くの瞬間を覚えました。 私はThorbjørnに、あなたが一番上の試行錯誤があるという事実に同意します。その内部では、例外をスローする可能性のある多くのメソッドを使用していることがわかります。エラー処理コードを避けるために、例外をキャッチすることをおすすめします。
について集中化、あなたのログファイルは十分に集中していると思います。