我想知道关于错误消息的普遍共识是什么。它们应该有多详细？
我参与过一些项目，其中输入一个太大、太小、有小数、是字符串等的数字时会出现不同的错误消息。这对用户来说非常好，因为他们知道哪里出了问题，但错误处理代码开始在大小上与实际业务逻辑相媲美，并开始开发一些自己的错误。
另一方面，我从事过一个项目，您会遇到非常普遍的错误，例如
编译失败原因 3
不用说几乎完全没用，因为原因 3 原来意味着链接错误。
那么中间地带在哪里呢？我如何知道我是否添加了足够多的描述性错误消息？我如何知道用户是否能够理解他们哪里出错了？
错误消息有两种可能的目标受众，用户和开发人员。
通常应该让消息针对用户。
o 问题的原因是什么。
o 为什么程序不能解决问题
o 用户可以做些什么来解决问题。
o 如何报告问题。
如果要报告问题，报告应包括尽可能多的程序上下文信息。
o 模块名称
o 函数名称
o 行号
o 问题的一般领域中感兴趣的变量
o 甚至可能是核心转储。
瞄准正确的受众。
你应该用尽可能少的语言来传达发生了什么，以及用户的选择是什么。错误消息越长，用户阅读它的可能性就越小。出于同样的原因，简短的错误消息是神秘而无用的。在长度方面有一个最佳点，并且在每种情况下都不同。
太短：
输入无效。
太长：
请输入格式正确的 IP 地址，例如 192.168.0.1。IP 地址是用于在网络上识别您的计算机的数字。
正好：
请输入有效的 IP 地址。
就代码膨胀而言，如果一些额外的代码会阻止用户致电支持或感到沮丧，那么这是一项很好的投资。
有两种类型的错误消息：用户可以看到的错误消息和程序员可以看到的错误消息。
“我怎么知道用户是否能够理解他们哪里出错了？” 我假设这些消息只会被用户看到，而不是非常技术性的消息，COMPILE FAILED REASON 3也不是典型的最终用户错误消息。这是程序员会看到的东西（用户通常不会编译东西）。
因此，如果是用户会看到它：
最后，为用户提供一些简单易懂的命令（“再试一次”、“取消”等）
关于错误消息的真正问题是是否应该显示它们。向用户显示了许多错误消息，但他们无法更正它们。
只要有办法纠正错误，就可以向用户提供足够的信息，让他们自己纠正错误。如果他们无法自行纠正，是否有任何理由告诉他们崩溃的技术原因？不只是将其记录到文件中以便以后进行故障排除。
尽可能详细；）
我知道这听起来像是一个聪明的答案，但这在很大程度上取决于您的目标受众和错误的类型。对于由无效用户输入引起的错误，您可以向他们展示什么是有效输入。对于用户无法控制的错误，通用的“我们正在处理它”类型的消息可能会起作用。
我也同意 Jon B 关于长度的评论。
错误消息应该详细但清晰。这可以通过组合来自多个级别的错误消息来实现：
Failed to save the image
Permission denied: /foo.jpg
这里我们有两个层次。可以有更多。首先我们讲大局，然后我们讲细节。顺序是这样的，首先我们有大多数人理解的部分，然后是较少人理解的部分，但两者仍然可以看到。
此外，可能会有修复建议。
我会在更详细的方面犯错，但我认为你回答了你自己的问题。为了避免代码膨胀，请在代码/错误消息中提供有用的信息，但您可以在文档中或帮助文件或常见问题解答中提供更多详细信息。
在我看来，信息太少会更糟。
如果您使用的是具有丰富自省或其他功能的语言，则带有未通过检查的行的日志将很有用。然后，用户可以转发给技术支持或以其他方式获取详细信息，这不是额外的代码膨胀，而是使用您自己的代码来提供信息。