有人真的使用 WARN 作为日志记录级别吗？ [关闭]答案

【问题标题】：Does anyone really use WARN as a logging level? [closed]有人真的使用 WARN 作为日志记录级别吗？ [关闭]
【发布时间】：2011-06-19 22:45:16
【问题描述】：

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

还有许多其他级别可以获得更多日志记录，这些级别可能更值得他们自己的级别 - 诸如“配置”之类的东西。然而，最终似乎大多数框架已经解决了错误、警告、信息、调试和跟踪及其变体。

那么警告是如何存活下来而其他级别却没有的呢？

【问题讨论】：

见stackoverflow.com/questions/2031163/…
@Raedwald 没有想到它只描述了api，它对警告没有区别。大多数方法只有 2 个结果，成功或一些异常结果（错误）。您可以将成功或结果打印为 INFO，任何有关计算的日志都将是 DEBUG。不需要警告，就像你不抛出警告，只抛出异常一样。
另见stackoverflow.com/questions/7839565/…
imo Warn -> 出了点问题，用户可能得不到他们想要的东西，但没有任何问题，他们也没有看到错误页面。 Error -> 东西破坏了用户看到一个错误页面。

标签： logging

【解决方案1】：

不同的日志级别很有用，因为开发人员希望在不同的时间完成不同的事情，即找到关键/致命错误 (ERROR) 的原因，或者维护程序并确保它正在执行预期的操作 (WARN )。

ERROR 表示程序/子例程根本无法继续，这可能代表了一个需要修复的严重错误，然后用户才能继续他们的任务。

WARN 表示开发人员没有预料到程序会这样做，但程序可能仍能满足用户要求。开发人员应定期检查日志中的 WARN 以确定是否需要更改（它们可能表明将来会出现问题）。理想情况下应该不会触发任何 WARN - 它们是开发人员更改某些内容的号召性用语。

【讨论】：

【解决方案2】：

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

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

【讨论】：

【解决方案3】：

我已将警告用于：

【讨论】：

听起来你描述的所有项目都是关于某个过程的“信息”。那么为什么会有差异呢？
@mP：取决于业务的要求。对于第一个，任何失败的登录都是信息级别的事件。连续多次被升级为警告。第三个类似。支持团队希望它在运行时记录（信息），在运行时间长时通知他们（警告），在运行时间超过配置的时间窗口时报告问题（错误），在运行失败时报告中断（致命/异常/等）。很多时候，它只是归结为企业希望报告的严重程度。
您仍然可以通过将不同的类别映射到不同的附加程序来解决问题。不同的问题将不同的消息记录到不同的类别。

【解决方案4】：

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

【讨论】：

如果数据错误就是错误，那不应该是错误。让日志记录类别成为过滤器并将“错误”（如不良数据）记录到该记录器。如果您想在该记录器上检查有关错误输入过滤器的消息。
@mP：但是“错误”是什么意思？该程序没有常识、一般知识或背景信息。它无法理解计算机操作员正在使用不寻常的配置运行特殊程序，因为他们正在准备升级。在这种情况下，操作员没有犯过错误，因此程序员不应假定将这种用法标记为错误。
我没有说数据有误。例如，我正在开发一个 POS 应用程序，它必须与信用卡提供商联系，并取回发卡行信用公司和清算信用公司 ID。有时，提供者返回 0 而不是正确的 ID。这不是错误，因为 id 仅在报告中使用，但怀疑可能出了问题。
@Miki 这就是为什么应该记录一个 INFO 提供者失败的再次尝试类型的消息。如果在尝试太多次之后仍然失败并且你放弃了，那么你会记录一个错误。
@Raedwald，这就是为什么您作为开发人员设置类别来描述不同类型的问题，并在出现问题时将您的消息记录到适当的目标。错误是意料之外的事情，并且对正在尝试的操作有害。一路上的评论是 INFO，打印变量等是 DEBUG。