当记录时是一个致命的错误?

Question

在记录框架，如log4j&log4net你有能力来记录各种级别的信息。大多数水平有明显的意图(比如什么一个"调试"日志与一个"错误").但是，有一件事我一直都是胆小的是进行分类的我的记录为"致命的".

什么类型的错误很严重，他们应被归类为致命的?虽然这是轻微的情况下驱动的，有些什么样的规则的拇指时所使用之间的决定记录例外，因为致命的或只是简单的错误？

Answer 1

我考虑的致命错误是，当应用程序可以不做任何更多的有益的工作。非致命错误是当有一个问题，但是你的申请仍然可以继续发挥作用，甚至在降低水平的功能或性能。

例的致命错误包括：

• 运行上的磁盘空间的日志记录的设备，你就要求保持记录。
• 总损失的网络连接在一个客户应用程序。
• 缺少配置的信息，如果不默认可使用。

非致命错误将包括：

• 一个服务器那里的一个单一届会议失败，由于某些原因但是你仍然可以服务的其他客户。
• 间歇性错误，如遗失会议，如果一个新会议可以成立。
• 缺少配置的信息，如果缺省值可以使用。

Answer 2

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

Answer 3

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

如果有可能恢复（例如，暂停重试失去网络连接），我不会使用致命的。

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

Answer 4

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

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

  

<！>“在设计早期制定实用，一致且合理的错误处理政策，然后坚持下去。<！>