Logging 有人真的使用WARN作为日志记录级别吗？

仅仅为警告而不是错误分配不同的级别似乎有点过分。如果一个值是错误的，它是错误的，它是正常的，它不是。就我个人而言，我认为这些模糊的决定使代码难以理解，因为人们不确定什么构成了可接受的有效输入。如果您不接受垃圾并抛出异常，那么您的代码可能会更好，完全不需要警告

还有许多其他级别获得了更多的日志记录，它们可能更值得拥有自己的级别—比如“config”。然而，最终看来，大多数框架已经解决了错误、警告、信息、调试和跟踪等问题

---

那么，警告是如何幸存下来的，而其他级别则没有？

当输入/数据有效且可接受时，我使用警告级别，但可能不适合当前应用程序状态，因此，如果我必须检查有关问题的日志，我将意识到数据可能存在问题。

我使用警告用于：

来自同一客户端的多次登录尝试失败。这不是一个错误，登录系统可以处理它，但有时需要注意尝试。（可能正在发生攻击，可能客户需要帮助等）

输入技术上不危险但可能需要人工监督的数据（用户在儿童友好网站上提交可能的粗话等）

一个过程花费的时间比预期的要长。还没有出错，但是支持团队想知道

---

对于我使用的软件，我使用以下区别

• 错误：程序无法执行要求它执行的操作。如果程序不能执行要求的操作，则需要输出错误消息
• 警告：程序检测到异常情况，但这并不阻止它执行要求它执行的操作。该程序可以（但不是必需的）输出异常情况下的警告消息

看来

例如，假设一个配置文件包含程序要检查的位置列表，该列表可能为空，但实际上从来都不是空的

• 如果配置文件的格式不正确，程序将报告错误消息，因为它无法计算出您希望它执行的操作，因此无法执行您想要的操作
• 如果配置文件没有列出任何位置，它可能会报告警告，因为尽管在这种情况下它可以正确地检查任何位置（即，不做任何有用的事情），但实际上用户可能没有正确地配置系统

---

不同的日志级别很有用，因为开发人员希望在不同的时间完成不同的任务，即查找关键/致命错误（错误）的原因，或维护程序并确保其执行预期的操作（警告）

错误意味着程序/子例程根本无法继续，这可能表示在用户可以继续执行任务之前需要修复的一个关键错误

---

警告意味着开发人员不希望程序这样做，但程序仍然可以满足用户需求。开发人员应定期检查日志中的警告，以确定是否需要更改（它们可能表示将来会出现问题）。理想情况下，不应该触发警告-它们是对开发人员进行更改的行动要求。

为什么不能使用信息而不是警告？我会使用信息来显示进度消息（“开始搜索X”）。听起来您描述的所有项目都是关于某个流程的“信息”。那么为什么会有差异呢？@mP：取决于业务的需求。对于第一个，任何失败的登录都是一个信息级别的事件。连续多个将升级为警告。第三个类似。支持团队希望在运行时记录（信息），在运行时间过长时通知他们（警告），在运行时间超过配置的时间窗口时报告问题（错误），在运行失败时报告停机（致命/异常/等等）。很多时候，问题的关键在于企业希望以何种严重性报告什么。您仍然可以通过将不同的类别映射到不同的附件来解决问题。不同的问题将不同的消息记录到不同的类别中。如果数据错误，那么它就是错误的，这不应该是错误的。让日志类别为过滤器，并将“错误”如坏数据记录到该记录器。如果要在该记录器上插入有关错误输入筛选器的消息。@mP:但“错误”是什么意思？该计划没有常识、常识或背景信息。它无法理解计算机操作员正在使用异常配置运行特殊程序，因为他们正在准备升级。在这种情况下，操作员没有犯错误，那么程序员就不应该假定这种用法是错误的。我没有说数据是错误的。例如，我正在开发一个POS应用程序，它必须到信用卡提供商那里，取回发卡机构信用公司并清算信用公司ID。有时，提供程序返回0而不是正确的ID。这不是一个错误，因为ID仅用于报告中，但怀疑可能出了问题。@Miki这就是为什么应该将信息记录到提供程序中，但重试失败的消息类型。如果多次尝试后仍然失败，并且您放弃了，那么您将记录一个错误。@Raedwald，这就是为什么您作为开发人员设置类别来描述不同类型的问题，并在出现问题时将消息记录到相应的目标。错误是不可预料的事情，对正在尝试的行为有害。一路上的注释是信息，打印变量等是调试。请参阅@Raedwald，answerhas no tho