什么时候记录是错误致命的？ [英] When logging when is an error fatal?

问题描述

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

什么类型的错误是如此严重，以致应该被归类为致命的？虽然这是一个小小的案例驱动，但是在将异常记录为致命或只是简单的错误时，您使用的一些大拇指规则是什么？

解决方案

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

致命错误的示例包括： / p>

• 记录设备上的磁盘空间不足，您需要继续记录。


• 客户端应用程序中网络连接的总损失


• 如果没有默认值，则缺少配置信息。

非致命错误将包括：

• 由于某种原因单个会话失败的服务器，但您仍然可以为其他客户端服务


• 如果可以建立新的会话，则会发生间歇性错误，例如丢失会话。


• 如果可以使用默认值，则缺少配置信息。

In logging frameworks like log4j & log4net you have the ability to log various levels of information. Most of the levels have obvious intentions (such as what a "Debug" log is vs. a "Error"). However, one thing that I have always been timid on was classifying my logging as "Fatal".

What type of errors are so severe that they should be classified as fatal? While this is slightly case driven, what are some of the rules-of-thumb that you use when deciding between logging an exception as fatal or just simply error?

解决方案

I consider fatal errors to be when your application can't do any more useful work. Non-fatal errors are when there's a problem but your application can still continue to function, even at a reduced level of functionality or performance.

Examples of fatal errors include:

• Running out of disk space on the logging device and you're required to keep logging.
• Total loss of network connectivity in a client application.
• Missing configuration information if no default can be used.

Non-fatal errors would include:

• A server where a single session fails for some reason but you can still service other clients.
• An intermittent error, such as lost session, if a new session can be established.
• Missing configuration information if a default value can be used.

这篇关于什么时候记录是错误致命的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！