按死亡顺序记录消息有不同的方法：
FATALERRORWARNINFODEBUGTRACE
我如何决定何时使用哪个？
什么是一个很好的启发式使用？
#1楼
我建议采用Syslog严重性级别： DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY 。
请参见http://en.wikipedia.org/wiki/Syslog#Severity_levels
它们应该为大多数用例提供足够的细粒度严重性级别，并且可以被现有的日志解析器识别。 虽然您当然可以自由地实施一个子集，例如DEBUG, ERROR, EMERGENCY具体取决于您的应用程序的要求。
让我们标准化已经存在多年的东西，而不是为我们制作的每个不同的应用程序提出我们自己的标准。 一旦开始聚合日志并尝试检测不同模式的模式，它确实有帮助。
#2楼
您可以从中恢复的警告。 错误你不能。 这是我的启发式，其他人可能有其他想法。
例如，假设您在应用程序中输入/导入名称"Angela Müller" （请注意u的变音符号）。 您的代码/数据库可能只有英文版（虽然它可能不应该在这个时代），因此可以警告所有“不寻常”的字符都已转换为普通英文字符。
与此相反，尝试将该信息写入数据库并将网络关闭消息直接返回60秒。 这更像是一个错误，而不是一个警告。
#3楼
如果您可以从问题中恢复，那么这是一个警告。 如果它阻止继续执行，那么这是一个错误。
#4楼
我之前构建了系统使用以下内容：
- 错误 - 意味着某些事情严重错误，并且特定的线程/进程/序列无法继续。 需要一些用户/管理员干预
- 警告 - 某些事情是不对的，但过程可以像以前一样继续进行（例如，100个集合中的一个作业失败，但其余部分可以处理）
在我建立的系统中，管理员正在接受指令以对ERROR做出反应。 另一方面，我们会关注警告并确定每种情况是否需要更改系统，重新配置等。
#5楼
您是否希望该消息让系统管理员在半夜起床？
- 是的 - >错误
- 不 - >警告
来源：oschina
链接：https://my.oschina.net/stackoom/blog/3161520