何时记录错误致命？

Question

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

什么类型的错误非常严重，以至于它们应该被归类为致命？虽然这是轻微的情况驱动，但在决定将异常记录为致命错误还是仅仅是错误时，您使用的一些经验法则是什么？如果缺少的东西或情况发生了该应用程序根本无法继续

Answer 1

我认为致命错误是，当你的应用程序不能做任何更多有用的工作。非致命错误是指出现问题时，即使功能或性能水平降低，您的应用程序仍可以继续运行。致命错误的

例子包括：

• 暗战的记录设备上的磁盘空间，你就必须保持记录。
• 客户端应用程序中网络连接的完全丢失。
• 如果不能使用默认值，缺少配置信息。

非致命错误将包括：

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

Answer 2

错误是致命的。可能的例子是缺少必需config.file或异常时“冒泡”，由未处理的异常处理程序捕获

Answer 3

如果我的下一步是要终止应用程序，或者仅仅不做任何后续工作，那么我会使用致命的。如果应用程序是批处理的一部分，或者有多个进程正在运行，这对追踪发生的事情可能很有用。

如果有痊愈的机会（例如，有重试了一段时间网络连接丢失），我不会用一个致命的。

如果我有一个主线程启动多个服务线程，因为一些错误的输入，但应用程序仍然可以成为新的请求，我不认为这是致命的其中之一失败。

Answer 4

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

但是分类错误，最重要的办法是坚持遵循拇指如第69条中C++ Coding Standards规则：

“在设计早期制定切实可行的，一致的，合理的错误处理策略，并然后坚持下去。“