「ログアンドスロー」がアンチパターンと見なされるのはなぜですか？[閉まっている]

この質問は、周りの議論によって引き起こされました 、私が良い答えを受け取らなかったこの記事。

他の方法で処理できない場合、例外をログに記録してから再スローする（もちろん元のスタックトレースを保持する）のはなぜ悪い考えですか？

答えは主に、それを処理できないのになぜそれを捕まえているのかということだと思います。ログに値すると感じた場合は、処理できる人（または処理する以外に選択肢がない人）にログを記録させてはどうでしょうか。

それをキャッチしてログに記録し、再スローすると、アップストリームコードが例外をログに記録したことを知る方法がないため、同じ例外が2回ログに記録される可能性があります。さらに悪いことに、すべてのアップストリームコードがこの同じパターンに従っている場合、例外は、キャッチしてログに記録してから再度スローすることを決定したコードのレベルごとに1回、任意の回数ログに記録される可能性があります。

また、例外のスローとキャッチは比較的コストのかかる操作であるため、このキャッチと再スローはすべてランタイムパフォーマンスに役立たないと主張する人もいるかもしれません。また、簡潔さや保守性の観点からもコードを支援するものではありません。

ログアンドスローは、例外をキャッチして再スローするエンティティが、少なくとも最も望ましい方法ではなく、コールスタックの上位にログに記録されない情報が含まれていると信じる理由がある場合に適したパターンです。これが発生する可能性のあるいくつかの理由：

1. 例外は、アプリケーション層の境界でキャッチおよび再スローされる可能性があり、特権情報が含まれる可能性があります。データベース層が例外を許可するのは悪いことです。たとえば、「重複するキー 'fnord'をフィールド 'users'に追加しようとしました」と言って、外部のアプリケーション層に到達します（これにより、ユーザーに公開される可能性があります）。データベースの内部がそのような例外をスローし、アプリケーションインターフェイスがそれをキャッチし、安全にログに記録し、やや説明の少ない例外を再スローするのに役立つ可能性があります。
2. 例外は、外層がロギングなしで処理することを期待している可能性が高いものですが、内層は外層が知らないことを知っている可能性があり、ロギングが役立つ可能性があることを示唆しています。大まかな例として、中間のアプリケーション層は、あるサーバーへの接続を試行し、それが機能しない場合は別のサーバーを試行するようにプログラムされている場合があります。サーバーがメンテナンスのためにダウンしているときに、アプリケーションのログを「接続に失敗しました」というメッセージで溢れさせることは、特に、アプリケーションの観点からはすべてが正常に機能したため、役に立たない場合があります。接続障害に関する情報をサーバーに関連付けられたロギングリソースに転送すると便利な場合があります。これにより、ログをフィルタリングして、接続の試行ごとのログではなく、サーバーがいつ上下したかに関するレポートを生成できます。 。

最も単純な理由は、通常、単一のトップレベルハンドラーがこれを実行するため、この例外処理でコードを汚染する必要がないことだと思います。

横断的関心事の議論は、基本的に、あなたに関係のないエラーを処理するのは時間の無駄であるということです。適切なハンドラーが見つかるまで、エラーがコールスタックをバブルアップさせる方がはるかに優れています。

私の意見では、例外をキャッチする必要があるのは、結果を使って何か役立つことができるときだけです。単にログを記録するためにキャッチすることは、その作業をさらに一元化できるため、役に立ちません。

IMOのログとスローは、驚き最小の原則の明らかな違反です。

例外がコールスタックのさらに上で適切に処理される場合、エラーログエントリの価値はまったくない可能性があります。そして、エラーログエントリを見つけるのは混乱します。