我有一个应用程序，它读取数据库并将警报输出到任何未满足的依赖项。我对这个问题的看法是“提供指向用户的最小信息”。一位同事告诉我，我应该尽可能地详细，打印出每个字段的数据库字段的值，我提到的最小消息是“字段1需要小于字段2”。 / p>
我知道这个问题必须有一些约定或标准，因为它让我想起了编译器错误和警告。有谁知道如何选择编译器消息？
社群对此问题有什么建议？
答案 0 :(得分：2)
我认为关键是要简明扼要。尽可能详细地说明要传达警告的原因所需的详细信息。
答案 1 :(得分：2)
写作时，要了解您的观众。
如果您正在为自己的消费记录警告/错误消息，那么这很简单：你在出现问题时需要知道什么？
如果您正在为其他人记录警告/错误消息，那么事情会变得棘手。他们知道什么？他们的系统心理模型是什么样的？他们解决了 可以解决的问题，以及解决这些问题需要哪些信息？
将最后一批数据推送到一条消息中是最好的 - 读者最多只需要浏览不相关的信息，以便找到他们需要的东西;在最坏的情况下，他们会变得困惑，最终根据错误的数据做出决定。
编译器类比很简单：想想如果整个符号表与每个警告一起被转储会有多烦人......
答案 2 :(得分：1)
对于正常的日常操作，我提供了一条数据验证消息，该消息提供了用户可以解决问题的足够信息，以便数据进行验证。例如，如果我有两个字段（fieldA和fieldB），其中一个字段必须大于另一个字段，那么我会在验证输出中声明，指定哪个字段是违规字段。
例如，如果A必须大于B，并且它们提供的答案小于B，那么消息将是“fieldA需要高于fieldB”
也就是说，我还将调试模式编程到我的应用程序（尤其是Web应用程序）中，这些应用程序具有详细模式，准确地告诉所有事情发生了什么。如果打开，你会看到两条消息，即用户友好的错误，然后“FieldA = XX和FieldB = YY：XX不大于YY”。
这是简化的，但这是一般的想法。
答案 3 :(得分：0)
我建议你应该实现这两种模式。在正常操作期间，您需要一条有用但短信息。但有时事情可能会出错，在这种情况下，“转储”模式可以为用户提供所有可能的信息，这是一种节省生命的方式。
答案 4 :(得分：0)
我认为3个典型用户组的错误消息有3个级别：
答案 5 :(得分：0)
可以讨论日志内容的具体内容，但根据我的经验，在 stress test 期间很快就会确定详细程度。
如果系统无法正常运行，那是因为你只是：
Atwood ：我们登录时日志调用期间的日志....正在触发另一个日志调用。这通常是好的，但是由于我们拥有的负载，最终它们会发生如此接近以至于还存在锁定。所以，那里有两个锁。
Spolsky ：[...]你倾向于记录所有内容。但是你只需要获得每个用户100兆字节的日志，并且你每分钟可以获得30个日志，并且无法以任何合理的方式对其进行分析或存储。所以你要做的下一件事就是开始剔除你的日志或者只是有不同级别的调试，就像在高调试模式下一样，所有内容都被记录下来，而在低调试模式下，没有任何记录。并且...在日志中找出你真正想要的东西很难。
Atwood ：具有讽刺意味的是，我认为要解决此问题，原因是日志记录，我们正在添加更多日志记录。
Spolsky ：[笑]
阿特伍德：这个笑话只是自己写的！这个笑话就是自己写的，对吧......
所以我的观点是，当您在类似生产的环境中运行系统时，您应该能够快速确定您选择的详细程度是否可持续。
答案 6 :(得分：-1)
处理错误。警告：错误应该是违反标准的事情。警告应该是允许的，但很可能不是作者的意图。
例如，W3C标记验证器将警告使用语法＆lt; br /＆gt;在HTML文档中。在XHTML中，这意味着“换行符”，但在HTML文档中，虽然被允许，但实际上意味着“换行符后跟一个大于号”（即使大多数浏览器都不尊重这一点）。
至于详细程度，最好的方法取决于谁在使用该系统。一些用户可以更好地使用他们可以浏览的简短消息，而其他用户（可能那些不太高级的用户）会发现其他信息很有用。如果不了解他们是谁，我倾向于使用标志（-v是传统的）让用户选择他们喜欢的版本。