错误消息应该有多详细?

错误消息有两个可能的目标受众:用户和开发人员。

一般情况下,消息应该以用户为目标。

o问题的原因是什么。
o为什么程序不能解决这个问题

o模块名称
o函数名
o线号

o甚至可能是堆芯倾倒。

您应该用尽可能少的语言传达发生了什么,以及用户的选项是什么。错误消息越长,用户读取它的可能性越小。出于同样的原因,短错误消息是神秘而无用的。就长度而言,有一个最佳点,每种情况都不同。

太短:

请输入格式正确的IP地址,如192.168.0.1。IP地址是用于在网络上标识计算机的数字。

恰到好处:

就代码膨胀而言,如果有一点额外的代码会阻止用户调用支持或受到挫折,那么这是一项很好的投资。

有两种类型的错误消息:用户可以看到的错误消息和程序员可以看到的错误消息。

我假设这些消息只会被用户看到,而不是一个非常技术性的消息,并且 COMPILE FAILED REASON 3

因此,如果是用户看到它:

1. 提供一个简短的“这是一条错误消息”(“操作!出现了问题!”,等等)
2. 提供错误的一般性描述(“您尝试连接的站点似乎不可用”/“您似乎没有足够的权限执行XYZ任务”/等等)

最后,为用户提供一些简单易懂的命令(“重试”、“取消”等)

关于错误消息的真正问题是它们是否应该被显示。向用户显示了大量错误消息,但用户无法更正这些错误消息。

尽可能详细;)

我知道这听起来像个聪明的回答,但这在很大程度上取决于你的目标受众和错误类型。对于由无效用户条目引起的错误,您可以向他们显示什么是有效条目。对于用户无法控制的错误,可以使用通用的“we's working it”类型消息。

我也同意Jon B关于长度的评论。

错误消息应该详细,但要清楚。这可以通过组合来自多个级别的错误消息来实现:

Failed to save the image
Permission denied: /foo.jpg

此外,可能还有修复建议。

我会在细节上犯错误,但我认为你回答了你自己的问题。为了避免代码膨胀,请在代码/错误消息中提供有用的信息,但您可以在文档中或帮助文件或常见问题解答中提供更多详细信息。

在我看来,信息太少更糟糕。