我有一个应用程序，它读取数据库并向任何未满足的依赖项输出警报。我对这个问题的想法是“提供将用户指向问题的最少信息”。一位同事告诉我，我应该尽可能详细，打印出我提到的每个字段的数据库字段的值，并给出“字段一需要小于字段二”的最小信息。
我知道这个问题必须有一些约定或标准，因为它提醒我编译器错误和警告。有谁知道如何选择编译器消息？
社区对此问题有什么建议？
【问题讨论】：
标签： database validation formatting user-interface
处理错误 Vs。首先警告：错误应该是针对违反标准的东西。警告应该是允许的，但很可能不是作者想要的。
例如，W3C 标记验证器将警告在 HTML 文档中使用语法
。在 XHTML 中，这意味着“换行符”，但在 HTML 文档中，虽然被允许，但实际上意味着“换行符后跟一个大于号”（即使大多数浏览器不尊重这一点）。
至于冗长，什么是最好的取决于谁在使用系统。一些用户会更好地使用他们可以浏览的简短消息，而其他用户（可能是那些不太先进的用户）会发现附加信息很有用。在不知道他们是谁的情况下，我倾向于使用标志（-v 是传统的）让用户选择他们喜欢的版本。
【讨论】：
可以讨论日志内容的细节，但根据我的经验，详细程度将在 stress test 期间很快确定。
如果系统无法正常运行，那是因为您只是：
Atwood：我们的日志记录方式是在日志调用期间日志....触发另一个日志调用。这通常是可以的，但是在我们的负载下，最终它们会发生得如此接近以至于还有一个锁。所以，那里有两把锁。
Spolsky：[...] 你有记录一切的倾向。但是你得到的只是每个用户一百兆字节的日志，你每分钟得到三十个，而且不可能以任何合理的方式分析或存储。所以接下来你要做的就是开始剔除你的日志，或者只是有不同级别的调试，就像在高调试模式下，一切都被记录下来，而在低调试模式下，什么都没有记录。而且...很难在日志中找出您真正想要的内容。
Atwood：我的意思是，讽刺的是，为了解决这个挂起的问题，原来是因为日志记录，我们增加了更多的日志记录。
斯波尔斯基：[笑]
阿特伍德：笑话自己写的！笑话自己写的，对吧……
所以我的观点是，当您将在类似生产的环境中运行系统时，您应该能够快速确定您选择的详细程度是否可持续。
【讨论】：
对于正常的日常操作，我会提供一条数据验证消息，该消息提供了足够的信息，用户可以解决问题，以便数据验证。例如，如果我有两个字段（fieldA 和 fieldB）并且其中一个必须大于另一个，那么我会在验证输出中说明这一点，并指定哪个字段是违规字段。
例如，如果 A 必须大于 B，并且他们提供的答案小于 B，那么消息将是“fieldA 需要高于 fieldB”
也就是说，我还在我的应用程序（尤其是 Web 应用程序）中编写了一个调试模式，它有一个详细模式，准确地告诉一切正在发生的事情。如果打开它，您会看到两条消息，一条用户友好的错误，然后是“FieldA=XX 和 FieldB=YY：XX 不大于 YY”。
这是简化的，但这是一般的想法。
【讨论】：
我认为对于 3 个典型用户组的错误消息的详细信息有 3 个级别：
【讨论】：
写作时，了解你的听众。
如果您记录警告/错误消息以供自己使用，那么这很容易：您在出现问题时需要知道什么？
如果您要为其他人记录警告/错误消息，那么事情就会变得棘手。他们知道什么？他们的系统心智模型是什么样的？他们可以解决什么样的问题，他们需要什么信息来解决这些问题？
将每条最后的数据都放入一条消息中是一种下注——充其量，读者将不得不浏览不相关的信息才能找到他们需要的信息；在最坏的情况下，他们会感到困惑并最终根据错误数据做出决定。
编译器的类比很贴切：想想如果整个符号表与每个警告一起被转储会多么烦人......
【讨论】：
我建议您应该实现这两种模式。在正常操作期间，您需要一条有用但简短的消息。但有时事情可能会出错，在这种情况下，为用户提供所有可能信息的“转储”模式可以挽救生命。
【讨论】：
我认为关键是要简洁。尽可能详细地说明传达警告的原因，仅此而已。
【讨论】：