12

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

4

12 回答 12

6

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

于 2008-09-22T20:17:00.317 回答
5

最终的最佳实践是首先防止用户造成错误。

不要告诉用户他们不关心的任何事情；错误代码 5064 对任何人都没有任何意义。不要告诉他们他们做错了什么；首先不允许它。不要责怪他们，尤其是你的软件所犯的错误。最重要的是，当出现问题时，告诉他们如何解决它，以便他们继续前进并完成一些工作。

于 2008-09-22T19:50:54.717 回答
2

一个好的错误信息应该：

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

我开始做的一件事是生成一个唯一编号，我会在错误消息中显示该编号并将其写入日志文件，这样当用户向我发送屏幕截图或致电并说“我出错了。它说我的参考号是 0988-7634"

于 2008-09-22T19:58:47.803 回答
2

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

于 2008-09-22T20:03:38.150 回答
1

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

于 2008-09-22T19:49:40.147 回答
1

尝试找出一种方法来编写您的软件，以便为他们解决问题。

于 2008-09-22T19:53:02.840 回答
1

对于任何用户输入（字符串、文件名、值等），始终显示错误值并在其周围加上分隔符（引号、括号等）。例如

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

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

于 2008-09-22T19:54:37.360 回答
1
  1. 避免来自不同地方的相同错误消息；如果可能，使用 file:line 进行参数化，或者使用其他上下文，让您（开发人员）唯一地识别错误发生的位置。
  2. 设计允许轻松本地化的机制，尤其是在它是商业产品的情况下。
  3. 如果错误消息是用户可见的，则使它们完整、有意义的句子不假定对代码有深入的了解；记住，你总是离问题太近了——用户不是。如果可能，请为用户提供有关如何进行、与谁联系等方面的指导。
  4. 如果可能，每个错误都应该有消息；如果没有，那么请尝试确保所有错误展开路径最终都会到达一条错误消息，以阐明所发生的事情。

    我相信这里会有其他好的答案......
于 2008-09-22T19:59:53.790 回答
1

实际上可以阅读较短的消息。

您的错误消息越长，用户阅读的内容就越少。话虽如此，请尝试重构代码，以便在有明显响应时消除异常。尽量只让基于超出您的用户或您的代码控制的事情发生的异常。

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

于 2008-09-22T20:00:18.237 回答
1

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

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

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

如果您可以轻松控制错误对话框，那么拥有一个显示漂亮、可读消息的对话框，其中带有“详细信息”按钮以显示错误号、跟踪等，这对于实时解决问题也有很大帮助。

于 2008-09-22T20:00:36.020 回答
0

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

于 2008-09-22T19:53:10.607 回答
0

我第二次不会告诉用户无用的深奥信息，例如数字错误代码。然而，我会跟进这一点，说一定要记录这些信息，以供更精通技术的人进行故障排除。

于 2008-09-22T19:53:22.260 回答