logging - 何时记录错误是致命的？

Question

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

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

Answer 1

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

致命错误的示例包括：

• 记录设备上的磁盘空间不足，您需要继续记录。
• 客户端应用程序中的网络连接完全丢失。
• 如果无法使用默认值，则缺少配置信息。

非致命错误包括：

• 单个会话由于某种原因失败但您仍然可以为其他客户端提供服务的服务器。
• 如果可以建立新会话，则会出现间歇性错误，例如会话丢失。
• 如果可以使用默认值，则缺少配置信息。

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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