何时记录错误是致命的？答案

【问题标题】：When logging when is an error fatal?何时记录错误是致命的？
【发布时间】：2010-09-23 17:21:38
【问题描述】：

在 log4j 和 log4net 等日志框架中，您可以记录各种级别的信息。大多数级别都有明显的意图（例如“调试”日志与“错误”日志的区别）。然而，我一直胆怯的一件事是将我的日志记录归类为“致命”。

什么类型的错误如此严重以至于它们应该被归类为致命错误？虽然这稍微取决于大小写，但在决定将异常记录为致命还是仅是错误时，您使用的一些经验法则是什么？

【问题讨论】：

【解决方案1】：

如果缺少某些内容或发生应用程序无法继续运行的情况，则错误是致命的。可能的示例是缺少必需的 config.file 或异常“冒泡”并被未处理的异常处理程序捕获时

【讨论】：

【解决方案2】：

我认为致命错误是指您的应用程序无法执行任何更有用的工作。非致命错误是指出现问题，但您的应用程序仍然可以继续运行，即使功能或性能级别有所降低。

致命错误示例包括：

非致命错误包括：

【讨论】：

网络连接丢失可能不是致命的。这可能是暂时的。
我的意思是“无法恢复”或“恢复时间过长”的完全损失，这就是非致命错误包括间歇性版本的原因。
不错的答案，但有一件事 - 应用程序如何轻松确定网络连接丢失是暂时的还是致命的？
@vikingsteve，它可以定期尝试x 秒（对于x 的一些合理值）。如果它恢复了，那是暂时的。如果不是，它是“永久的”。这是一种可能性。或者，如果 7 个线程可以正常通信，而只有第 8 个线程有问题，那也可能是非完全损失。
在异常树的上环中使用 Fatal，大多数时候这是控制台应用程序的 Main void 中的 try-catch 块或 ASP.NET/MVC 应用程序的 Application_Error 或在 WCF 服务的情况下的 ErrorHandler 行为。当您作为程序员拥有完全控制权并希望记录特殊故障情况但您有可恢复的回退路径（例如默认值）时，请使用错误。

【解决方案3】：

如果我的下一步是终止应用程序，或者只是不再执行任何后续工作，我会使用 fatal。如果应用程序是批处理的一部分或有多个进程正在运行，这对于跟踪发生的事情很有用。

如果有恢复的机会（例如，网络连接丢失并重试一段时间）我不会使用致命的。

如果我有多个服务线程被一个主线程激活，其中一个由于输入错误而失败，但应用程序仍然可以处理新请求，我认为这不是致命的。

【讨论】：

【解决方案4】：

为了使这个答案简短而甜蜜，如果您的应用程序崩溃，我会认为这是致命的。如果您无法连接到数据库或所需服务等重要资源，那将是致命的。总的来说，我会说如果它使您的应用程序无法正常运行并影响用户，我会将其归类为致命错误。

但对错误进行分类最重要的方法是始终遵循经验法则，例如 C++ Coding Standards 中的规则 69：

“在设计初期制定实用、一致和合理的错误处理策略，然后坚持下去。”

【讨论】：