错误消息文本 - 最佳实践

Question

我们正在更改旧的，写得不好的错误消息的一些文本。有关编写良好错误消息（特别是Windows XP / Vista）的最佳实践的一些资源。

Answer 1

在措辞错误消息方面，我建议您参考以下Windows应用程序的样式指南：

• Windows user experience guidelines，特别是关于错误消息here的部分。
• Microsoft Manual of Style

Answer 2

最佳的最佳做法是防止用户首先导致错误。

不要告诉用户他们不关心的事情;错误代码5064并不代表任何人的事情。不要告诉他们他们做错了什么;首先不允许它。不要责怪他们，特别是不要因为你的软件犯了错误。最重要的是，当出现问题时，告诉他们如何修复它以便他们继续前进并完成一些工作。

Answer 3

一条好的错误信息：

• 不引人注目（没有蓝屏或黄屏死机）
• 让用户指示纠正问题（如果可能，或者联系谁寻求帮助）
• 隐藏无用的，深奥的程序员废话（不要说，“第45行发生空引用异常”）
• 描述性而不冗长。足够的信息告诉用户他们需要知道什么，仅此而已。

我开始做的一件事是生成一个我在错误消息中显示的唯一编号并写入日志文件，以便当用户向我发送屏幕截图或调用时我可以在日志中找到错误并说，“我收到了一个错误。它说我的参考号是0988-7634”

Answer 4

出于安全原因，请勿提供用户不需要的内部系统信息 琐碎的例子：当登录失败时，不要告诉用户用户名是错误还是密码错误;这只会帮助攻击者暴力破解系统。相反，只需说“用户名/密码组合无效”或类似的东西。

Answer 5

始终包含纠正错误的建议。

Answer 6

尝试找出一种编写软件的方法，以便纠正它们的问题。

Answer 7

对于任何用户输入（字符串，文件名，值等），始终显示错误值及其周围的分隔符（引号，括号等）。 e.g。

找不到您输入的文件名：“somefile.txt”

这有助于显示可能已经潜入的任何空格/回车，并大大减少故障排除和挫败感。

Answer 8

1. 避免来自不同地方的相同错误消息;如果可能，使用file：line进行参数化，或者使用其他上下文，让开发人员可以唯一地识别错误发生的位置。
2. 设计机制以便于本地化，特别是如果它是商业产品。
3. 如果错误消息是用户可见的，请将它们作为完整的，有意义的句子，不要对代码有深入的了解;记住，你总是太接近问题 - 用户不是。如果可能，请向用户提供有关如何继续，联系人等的指导。
4. 如果可能，每个错误都应该有一条消息;如果没有，那么请尝试确保所有错误展开路径最终都会出现错误消息，从而揭示发生的事情。
   
   我相信这里还有其他好的答案......

Answer 9

实际上可以读取更短的消息。

错误消息越长，用户读取的内容就越少。话虽如此，尝试重构代码，以便在有明显响应的情况下消除异常。尽量只根据用户或代码控制之外的事情发生异常。

最好的异常消息是您永远不必显示的消息。

Answer 10

错误处理始终优于错误报告，但由于您正在改进错误消息，而不一定是代码，这里有一些建议：

用户需要解决方案，而不是问题。帮助他们知道错误后要做什么，即使消息像“请关闭当前窗口并重试您的操作”一样简单。

我也是集中记录错误的忠实粉丝。确保日志是人类和计算机可扫描的。用户并不总是让您知道他们遇到了什么问题，特别是如果他们可以“解决”，所以日志可以帮助您了解需要修复的内容。

如果你可以轻松地控制错误对话框，那么显示一个带有“详细信息”按钮的漂亮可读消息的对话框可以显示错误编号，跟踪等，这对于实时解决问题非常有帮助。好。

Answer 11

支持多语言适用于所有类型的消息，但在出现错误消息时往往会被遗忘。

Answer 12

我不会告诉用户无用的深奥信息，如数字错误代码。我会遵循这一点，但要明确记录这些信息，以便让技术娴熟的人进行故障排除。