错误消息是显示用于描述导致用户或系统无法完成任务的问题的文本。 此问题可能会导致数据损坏或丢失。 其他消息类型包括确认、警告和通知。 本主题中的准则旨在帮助你编写易于本地化且对客户有用的清晰错误消息。
编写不当的错误消息可能是用户感到沮丧的源泉，可以增加技术支持成本。 编写良好的错误消息向用户提供以下信息：
- 发生了什么，为什么？
- 用户的最终结果是什么？
- 用户可以做些什么来防止它再次发生？
只要开发人员正确处理缓冲区大小，文本的长度就不是问题。 用户必须具备解决问题所需的所有信息。 如果邮件具有多个受众，则可能需要为管理员、最终用户和开发人员提供单独的文本。
最佳做法
以下是改进错误消息的方法：
- 避免错误条件。 如果可以预测用户在执行特定作时会发生错误，请重写代码，使用户无法导致错误。
- 为每个已知错误原因编写单独的错误消息。 请勿使用单个泛型消息来解释错误的每个可能原因，除非在发生错误时无法确定错误的原因。
- 明确说明问题，如果对用户有帮助，请解释导致问题的原因。 尽可能将系统消息表资源的泛型消息替换为特定于问题的详细消息。
- 向用户提供问题的解决方案。 如果解决方案具有多个步骤，请参阅帮助主题，详细说明任务。
- 仅在消息的标题栏中显示产品、组件或向导名称。 这有助于用户确定问题所在位置。 不要在标题栏中汇总问题，或包括“error”一词。
- 请勿使用技术行话，请使用受众理解的术语。 请勿使用俚语或缩写。
- 使用相应的命令按钮，例如“确定”、“取消”、“是”、“否”和“重试”。 可以使用这些按钮的组合。 “是”和“否”按钮必须始终组合使用，并且必须始终前面有问题。
- 若要停止作并关闭消息框，请使用“取消 ”按钮。
- 若要关闭消息框，请使用“关闭 ”按钮。
- 若要提供有关错误原因的详细信息，请使用 详细信息 按钮。
- 若要提供有关问题解决方案的详细信息，请使用 帮助 按钮。
- 如果消息中包含用户作，请使用 “确定” 按钮关闭消息框。
- 是，并且 不能结合使用任何 按钮，并且必须始终先于问题。
- 如果错误是严重错误，请将其写入 事件日志。
样式注意事项
- 使用完整但简单的句子。
- 使用当前时态描述导致问题的条件或仍然存在的状态。 可以使用过去时态来描述过去发生的不同事件。
- 尽可能使用活动语音。 可以使用被动语音描述错误情况。
- 避免大写文本和感叹号。
- 即使问题是用户错误的结果，也不要使用户感到出错。
- 不要进行人为化。 不要暗示程序或硬件可以思考或感觉。
- 不要使用口语单词或短语。 不要使用在某些文化中可能令人反感的术语。
- 不要在添加谓词或子词的情况下复合几个名词来阐明含义。 例如，“站点服务器 LDAP 服务目录服务器”应更改为“站点服务器的 LDAP 服务的目录服务器”。
- 在术语前插入描述符，以阐明句子的含义。 例如，“当 Detect 设置为 No 时指定 InfID。”应更改为“在 Detect 选项设置为 No 时指定 InfID 参数”。
- 避免单词“bad”。 使用更具描述性的术语告知用户错误。 例如，请避免出现“大小错误”等消息。 而是告诉用户指定大小时要使用的条件。
- 避免出现“请”一词。 可以解释为意味着所需的作是可选的。
- 在索引中放置与消息字符串开头的中心含义相关的字词。