logo标签列表

错误信息文本 - 最佳实践

user-interfaceerror-handlingusability
12

我们正在更改一些旧的、写得很糟糕的错误消息的文本。有哪些关于编写良好的错误消息最佳实践的资源可以使用（特别针对Windows XP/Vista）？

很好地详细说明你的受众是谁会很不错：最终用户？开发人员？ - rlerallut
12个回答
6
5

最佳实践是在第一时间防止用户产生错误。

不要告诉用户任何他们不关心的信息，例如错误代码5064对任何人来说都没有意义。在第一时间就禁止用户做错事情，不要责怪他们，尤其不要因为你的软件出错而责怪他们。最重要的是，在出现问题时，告诉他们如何修复，这样他们可以继续工作。

我认为编写错误消息并不完全涉及设计用户界面对错误的反应。你可以在某个地方记录非常好的错误消息，用户不需要看到它们。 - Sergio Acosta
2
一个好的错误信息应该能够：
  • 不引人注目（不要出现蓝屏或黄屏死机）
  • 给用户指出如何自行解决问题，或者提供联系人以获取帮助。
  • 隐藏无用的、晦涩难懂的程序员专业术语（不要说，“发生了空引用异常，位于第45行”）
  • 简单明了地描述问题，不啰嗦。只提供足够的信息告诉用户需要知道的内容，不多不少。

我开始采用的一种方法是，在错误信息中显示并记录一个唯一编号，这样当用户向我发送截图或打电话说“我遇到了一个错误，它显示我的参考编号是0988-7634”时，我可以在日志中找到对应的错误信息。

2

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

1

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

1

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

1
对于任何用户输入（字符串、文件名、值等），始终使用定界符（引号、括号等）显示错误的值。例如：

您输入的文件名无法找到："somefile.txt"

这有助于显示可能已经混入的任何空格/回车，并极大地减少了故障排除和挫败感。
1
  1. 避免来自不同位置的相同错误消息; 如果可能，将其参数化为文件：行，或者使用其他上下文让您，开发人员，唯一确定错误发生的位置。
  2. 设计机制以允许轻松本地化，特别是如果它是商业产品。
  3. 如果错误消息是用户可见的，请使它们成为完整，有意义的句子，不要假定对代码有亲密了解; 记住，你总是过于接近问题 - 用户不是。如果可能，为用户提供如何进行操作，联系谁等指导。
  4. 尽可能每个错误都应该有一个消息; 如果不行，则尝试确保所有错误展开路径最终都达到可以阐明发生了什么的错误消息。

    我相信这里会有其他好的答案...
1

短信息可能会被阅读。

错误信息越长，用户阅读的可能性就越小。话虽如此，请尝试重构代码，以便在有明显响应时消除异常。尽量只有在超出用户或代码控制范围的情况下才发生异常。

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

1

错误处理总比错误报告更好，但由于您正在改装错误消息而不一定是代码，因此这里有几个建议：

用户想要解决方案，而不是问题。帮助他们知道在出现错误后该怎么做，即使消息只是简单的“请关闭当前窗口并重试您的操作”。

我也非常喜欢集中记录错误。确保日志既适合人类阅读，也适合计算机扫描。用户并不总是让您知道他们遇到了什么问题，特别是如果可以“绕过”，因此日志可以帮助您了解哪些问题需要修复。

如果您可以轻松控制错误对话框，则具有漂亮、易读的消息和“详细信息”按钮以显示错误编号、跟踪等的对话框也可以大大帮助实时问题解决。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接