log4j や log4net などのログ フレームワークでは、さまざまなレベルの情報をログに記録できます。ほとんどのレベルには明確な意図があります (「デバッグ」ログと「エラー」など)。ただし、私が常に臆病であったことの 1 つは、ログを「致命的」に分類することでした。
致命的と分類する必要があるほど重大なエラーのタイプはどれですか? これはわずかにケース ドリブンですが、例外を致命的としてログに記録するか、単にエラーとしてログに記録するかを決定する際に使用する経験則にはどのようなものがありますか?
致命的なエラーは、アプリケーションがこれ以上有用な作業を実行できない場合に発生すると考えています。致命的ではないエラーとは、問題が発生したものの、機能やパフォーマンスのレベルが低下しても、アプリケーションは機能し続けることができるエラーです。
致命的なエラーの例は次のとおりです。
致命的ではないエラーには次のものがあります。
何かが不足している場合、またはアプリケーションを続行できない状況が発生した場合、エラーは致命的です。考えられる例としては、必要な config.file が欠落している、または例外が「バブルアップ」し、未処理の例外ハンドラーによってキャッチされた場合です。
次のステップがアプリケーションを終了することである場合、または単に後続の作業を行わない場合は、fatal を使用します。アプリケーションがバッチの一部であるか、複数のプロセスが実行されている場合、これは何が起こったかを追跡するのに役立ちます。
回復の可能性がある場合 (たとえば、しばらく再試行するとネットワーク接続が失われる場合)、私は致命的を使用しません。
メイン スレッドによってアクティブ化された複数のサービス スレッドがあり、そのうちの 1 つが不適切な入力のために失敗した場合でも、アプリケーションは引き続き新しい要求を処理できますが、それは致命的ではないと考えています。
この答えを簡潔かつ適切にするために、アプリケーションがクラッシュした場合、それは致命的であると考えます。データベースや必要なサービスなどの重要なリソースに接続できない場合、それは致命的です。全体として、アプリケーションが正常に動作しなくなり、ユーザーに影響を与える場合、それは致命的なエラーに分類されます。
ただし、エラーを分類する最も重要な方法は、 C++ コーディング標準のルール 69 などの経験則に一貫して従うことです。
「設計の早い段階で、実用的で一貫性のある合理的なエラー処理ポリシーを開発し、それを守ります。」