ラップされた例外をログに記録すると、通常、ラッパーに関する長いスタック トレースが取得され、余裕がある場合は実際の根本原因の数行が取得されます。しかし、根本的な原因は、スタックトレースを読みたい例外です!
私は自分のアプリのほとんどの例外を、自分が制御するカスタム例外でラップしています。(理由は以下の背景にあります。) このロギングの問題を解決するために、カスタム ラッパーの例外で、構築時にスタック トレースのほとんどを単純に削除することは合理的ですか?
ラッパーが構築されているときにスタックトレースのほとんどを削除すると、すべてが美しくログに記録されます.log4jは、例外とその原因に関するn行のログを出力するようです。根本原因に関するスタック トレース。
トレースの最初の行以外のことを知りたい状況は考えられませんが、スタックトレース情報を削除することについて何かが私を悩ませています。私は経験が浅く、自分の直感が正しいのか、異常な状況に不快感を覚えているだけなのか、判断がつきません。これの何が問題なのか誰にも教えてもらえますか?
関連する場合の背景:
私は、大規模な Java Web アプリケーションで適切なエラー処理を行うための合理的な最初のパスを見つけようとしています。私の現在の計画は、例外が発生したときにカスタム例外でラップし、ログに記録される最上位レベルまでバブルアップさせることです。(カスタム ラッパーを使用して、表示されるすべての例外に一意の ID を関連付けたいと考えています。これにより、その ID を UI に伝達し、事後でも関連するログを簡単に見つけることができます。)
これは、チェーンされた例外をログに記録するタイミングに密接に関連するフォローアップの質問です。、チェーンされた例外をログに記録する方法について心配していたので、後続のラッパーに関する無駄なスタックトレースの束よりも実際の原因についてより多くの情報を取得できます. 提案の 1 つ (すべてのレイヤーをチェーン化するのではなく、ログを制御できる最上位レイヤーに例外をバブルアップさせる) は合理的であり、最上位レベルに到達する限り、コードを 1 か所に配置するのは簡単です。ラッパーの代わりに根本原因をログに記録します。しかし、これらの例外のいずれかをキャッチしてログに記録する必要がある場合は、デフォルトのログ記録の動作に再び行き詰まります。