错误消息详细程度的最佳实践是什么？
我想知道关于错误消息的普遍共识是什么。 它们应该有多详细？
我曾经参与过一些项目，其中输入的数字太大、太小、有小数、是字符串等时会出现不同的错误消息。这对用户来说非常好，因为他们确切地知道哪里出了问题，但是错误处理代码在大小上开始与实际业务逻辑竞争，并开始产生一些自己的错误。
另一方面，我参与了一个项目，在该项目中您会遇到非常普遍的错误，例如
编译失败原因3
不用说，它几乎完全没有用，因为“原因 3”最终意味着链接错误。
那么中间立场在哪里呢？ 我如何知道我是否添加了足够描述性的错误消息？ 我如何知道用户是否能够理解他们哪里出了问题？
I was wondering what the general consensus on error messages was. How detailed should they be?
I've worked on projects where there was a different error message for entering a number that was too big, too small, had a decimal, was a string, etc. That was quite nice for the user as they knew exactly where things went wrong, but the error handling code started to rival the actual business logic in size, and started to develop some of its own bugs.
On the other side I've worked on a project where you'd get very generic errors such as
COMPILE FAILED REASON 3
which, needless to say, was almost entirely useless as "reason 3" turned out to mean a link error.
So where is the middle ground? How do I know if I've added descriptive enough error messages? How do I know if the user will be able to understand where they've gone wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
错误消息有两个可能的目标受众：用户和开发人员。
通常应该将消息瞄准用户。
如果要报告问题，报告应包含尽可能多的程序上下文信息。
瞄准正确的受众。
There are two possible target audiences for an error message: the user and the developer.
One should generally have the message target the user.
If the problem is to be reported, the report should include as much program context information as possible.
Target the correct audience.
您应该用尽可能少的文字来传达发生的情况以及用户的选择。 错误消息越长，用户阅读它的可能性就越小。 同样的道理，简短的错误消息是神秘且无用的。 长度有一个最佳点，而且每种情况下都有不同的长度。
过短：
太长：
正好：
就代码膨胀而言，如果一点额外的代码可以防止用户致电支持或感到沮丧，那么这是一项很好的投资。
You should communicate what happened, and what the user's options are, in as few words as possible. The longer the error message is, the less likely the user is to read it. By the same token, short error messages are cryptic and useless. There's a sweet spot in terms of length, and it's different for every situation.
Too short:
Too long:
Just right:
As far as code bloat is concerned, if a little extra code will prevent a user from calling support or getting frustraited, then it's a good investment.
有两种类型的错误消息：用户会看到的错误消息和程序员会看到的错误消息。
“我怎么知道用户是否能够理解他们哪里出了问题？”
我假设这些消息只会被用户看到，而不是非常技术性的消息，并且
COMPILE FAILED REASON 3不是典型的最终用户错误消息。 这是程序员会看到的东西（用户通常不编译东西）。因此，如果用户会看到它：
最后，为用户提供一些简单易懂的命令（“重试”、“取消”等）
There are two types of error messages: Those that will be seen by the user and those that'll be seen by the programmer.
"How do I know if the user will be able to understand where they've gone wrong?"
I'm assuming that those messages are only going to be seen by the user, and not a very technical one, and
COMPILE FAILED REASON 3is not a typical end-user error message. It's something that the programmer will see(the user doesn't usually compile things).So, if it's the user that'll see it:
Finally, provide some simple and understandable commands for the user ("Try again", "Cancel", etc.)
错误消息应该详细但清晰。 这可以通过组合来自多个级别的错误消息来实现：
这里我们有两个级别。 还可以有更多。 首先我们讲述大局，然后我们讲述细节。 顺序是这样的，首先是大多数人理解的部分，然后是较少人理解的部分，但两者仍然是可见的。
此外可能还有修复建议。
Error messages should be detailed, but clear. This can be achieved by combining error messages from multiple levels:
Here we have two levels. There can be more. First we tell the big picture and then we tell the details. The order is such that first we have the part understood by most and then the part less people understand, but both can still be visible.
Additionally there could be a fix suggestion.
关于错误消息的真正问题是是否应该显示它们。 许多错误消息呈现给用户，但他们没有办法纠正它们。
只要有办法纠正错误，就向用户提供足够的信息，让他们能够自行纠正错误。 如果他们无法自行纠正，是否有理由告诉他们崩溃的技术原因？ 不只是将其记录到文件中以便稍后进行故障排除。
The real question about error messages is if they should even be displayed. A lot of error messages are presented to a user but there is NO WAY for them to correct them.
As long as there is a way to correct the error then give enough information to the user that will allow them to correct it on their own. If they are not able to correct it on their own is there any reason to tell them the technical reason for the crash? No just log it to a file for troubleshooting later.
尽可能详细；）
我知道这听起来像是一个聪明的答案，但这很大程度上取决于您的目标受众和错误类型。 对于由无效用户输入引起的错误，您可以向他们显示什么构成有效输入。 对于用户无法控制的错误，通用的“我们正在处理它”类型的消息可能会起作用。
我也同意 Jon B 关于长度的评论。
As detailed as they need to be ;)
I know it sounds like a smart ass answer but so much of this depends on your target audience and the type of error. For errors caused by invalid user entry, you could show them what constitutes a valid entry. For errors that the user can't control, a generic "we're working on it" type message might do.
I agree with Jon B's comments regarding length as well.
我会错误地提供更多细节，但我认为您回答了自己的问题。 为了避免代码膨胀，请在代码/错误消息中提供有用的信息，但您可以在文档中或通过帮助文件或常见问题解答提供更多详细信息。
我认为信息太少会更糟糕。
如果您使用的语言具有丰富的自省或其他功能，则包含检查失败的行的日志将很有用。 然后，用户可以转发给技术支持或以其他方式获取详细信息，这不是额外的代码膨胀，而是使用您自己的代码来提供信息。
I would err on the side of more detail, but I think you answered your own question. To avoid the bloat in code then provide useful information in the code/error message but you can give more details in the documentation perhaps or with help files or FAQ.
having too little information is worse in my opinion.
If you are using a language with rich introspection or other capabilities, a log witht he line that failed a check would be useful. The user can then forward to tech support or otherwise get detailed information and this is not additional code bloat, but using your own code to provide information.