私はかなり大きなWebアプリをリファクタリングしています。主な問題の1つは、一貫性のないエラー処理であり、私は賢明な戦略を考え出そうとしています。set_error_handlerを介して、基本的にErrorExceptionsの PHPエラーを変換するカスタムエラーハンドラーと、Exceptionから直接継承するカスタムベース例外クラスを作成しました。
実稼働環境では、set_exception_handlerを介して汎用の例外catch-allを使用しており、例外ログ*をミックスに追加しようとしています。私のジレンマは、基本例外クラスまたはキャッチオールで実際のロギングを行う場所です。
私はそれをキャッチオールに記録するいくつかの理由を考えました：
- 基本例外クラスの適切な子に変換する必要があるコードには、かなりの数の例外があります。それが起こるまで、すべての例外がログに記録されるわけではありません。
- キャッチオールでそれを行う方が自然な感じがします。ベース例外クラスはそれ以上のことをすべきではありません。（それは単一の責任原則のことかもしれませんが、見当違いの感覚かもしれません）
基本例外クラスにログインする1つの理由：
- 現在、キャッチオールは本番環境でのみ使用されています。他の環境（開発、テスト）で導入するのは簡単ですが、エラーは環境ごとに処理が異なるため、本番環境では404/503エラーページに変換されるため、いくつかの調整が必要になります。
例外をログに記録する場所について、受け入れられるプラクティスはありますか？
*ロギングには最初はテキストファイルへの書き込みが含まれますが、特定の種類の例外のメールを送信するように進化する場合があります。
@unholysamplerの答えに促されたいくつかの説明：
私は2 * 10 ^ 6のslocコードベースに直面しており、多くのサードパーティのものを制御できません。また、PHPの前日例外を制御するコードの一部もあります。また、最近のくだらないコードもいくつかあります。私たちは、思考をやめ、ハッキングされなければならなかった激しいプレッシャーから長期間回復しています。
すべての矛盾に対処し、適切なエラー処理アプローチを導入するために積極的にリファクタリングを行っていますが、それには時間がかかります。エラーが適切に処理されるようになるまで、どうすればいいのか興味があります。おそらく、ある時点で賢明な例外戦略について別の質問をするでしょう。
ロギングの背後にある主な動機は、本番環境で何か悪いことが起こったときに電話でメールを受け取ることです。データダンプが巨大になるかどうかは気にしません。データダンプが大きくなると、古いジョブを時々削除するcronジョブが必要になります。