我有一个读取数据库并向未满足的依赖项输出警报的应用程序。我对这个问题的想法是"提供将用户指向该问题的最少信息"。一位同事告诉我，我应该尽可能地冗长，打印出我提到的每个字段的数据库字段的值，这些经文给出的最小信息是"字段一需要小于字段二"。

我知道此问题必须有一些约定或者标准，因为它使我想起了编译器错误和警告。有谁知道如何选择编译器消息？

社区对此问题有何建议？

解决方案

我认为关键是要简洁。尽可能详细地传达警告的原因，仅此而已。

我建议我们同时实现两种模式。在正常操作期间，我们需要一条有用的但简短的消息。但是有时情况可能会出错，在这种情况下，为用户提供所有可能信息的"转储"模式可以节省生命。

在写作时，要了解你的听众。

如果我们要记录警告/错误消息以供自己使用，那么这很容易：什么时候出问题了，我们需要知道什么？

如果我们正在记录其他人的警告/错误消息，那么事情会变得很棘手。他们知道什么？他们的系统心理模型是什么样的？他们可以解决什么类型的问题，以及他们需要解决什么信息？

将每条最后的数据推送到一条消息中充其量只是在捣乱，读者将不得不遍历不相关的信息才能找到所需的内容。最糟糕的是，他们会感到困惑，最终会根据错误的数据做出决策。

编译器比喻是恰当的：想想如果将整个符号表与每个警告一起转储，那将是多么烦人……

处理错误VS。首先警告：错误应归咎于违反标准的内容。警告应该是允许的，但很可能不是作者想要的。

例如，W3C标记验证器将警告在HTML文档中使用语法<br />。在XHTML中，这表示"换行符"，但是在HTML文档中，虽然允许使用，但实际上是指"在换行符后加一个大于号"(即使大多数浏览器都不遵守)。

至于冗长，什么才是最好的取决于谁在使用该系统。一些用户可以浏览一些简短的消息会更好，而其他用户(也许是那些不太高级的用户)会发现其他有用的信息。在不了解他们是谁的情况下，我倾向于使用标志(-v是传统标志)让用户选择他们喜欢的版本。

我认为针对3个典型用户组，错误消息的详细信息分为3个级别：

• 最终用户。这是网站上的冲浪者或者桌面应用程序的用户。如果无法解决问题，他应该收到一条错误消息。它应包括最少的信息。最终用户不应通过系统接收任何信息，例如当前配置和文件路径。最终用户应与管理员联系。连续的错误ID有助于管理员找到更多信息。
• 管理员需要更多有用的信息来自行解决问题。它可能包含诸如表xy找不到或者登录数据库失败之类的信息。
• 开发人员：如果管理员无法解决问题，则它将与软件供应商联系。在这种情况下，管理员应该能够发送日志文件，供开发人员在无法重现该问题时也可以解决该问题。

对于正常的日常操作，我提供了一条数据验证消息，该消息提供了足够的信息，用户可以解决该问题，从而对数据进行验证。例如，如果我有两个字段(fieldA和fieldB)，并且其中一个必须大于另一个，那么我将在验证输出中指出，指定哪个字段为违规字段。

例如，如果A必须大于B，并且它们提供的答案小于B，则消息将为" fieldA需要高于fieldB"

就是说，我还对我的应用程序(特别是Web应用程序)中的调试模式进行了编程，该模式具有冗长的模式，可以准确地告诉一切情况。如果将其打开，则会看到两条消息，即用户友好错误，然后显示" FieldA = XX和FieldB = YY：XX不大于YY"。

简化了，但这是一般的想法。

可以讨论日志内容的具体细节，但是据我的经验，在压力测试过程中，详细程度将很快确定。
如果系统无法正常运行，那是因为我们只是：

• 或者对日志太冗长，或者
• 确实记录得太多了(实际上，我相信杰夫本人也有类似的问题)

Atwood: We were logging in such a way that the log.... during the log call was triggering another log call. Which is normally okay, but with the load that we have, eventually they would happen so close together that there's also a lock. So, there's two locks going on there.
  
  Spolsky: [...] you have a tendency to wanna log everything. But then you just get logs that are, you know, a hundred megabyte per user and you get thirty of them a minute and it can't possibly be analyzed or stored in any reasonable way. So the next thing you have to do is to start culling your logs or just have different levels of debugging, where it's like in high debug mode everything is logged and in low debug mode nothing is logged. And... it's kind of hard to figure out what you really want in a log.
  
  Atwood: I mean that, ironically, to troubleshoot this hang, which turned out to be because of logging, we were adding more logging.
  
  Spolsky: [laughs]
  
  Atwood: The joke just writes itself! The joke just writes itself, right...

所以我的意思是，当我们要在类似生产的环境中运行系统时，我们应该能够迅速确定所选的详细程度是否可持续。