如何编写好的错误信息？
虽然这不是编程语言问题，但程序员必须在客户或其他人没有提供副本的情况下做这件事。 任何错误信息的例子，无论好坏，都欢迎提出意见。
我简单地search，找不到一个骗局线程。 好吧，有。 谢谢，所有。
- 道歉。
- 说出了什么问题。
- 说出如何解决它。
- 要有礼貌。
- 该信息应该措辞，以便应用程序接受问题的责任。 不要责怪或批评用户，也不要让他们认为这是他们的错。
例：
“对不起，该文件无法打开，请检查该文件是否已被其他程序打开，然后重试。”
如果有更多的细节会吓倒用户，比如错误号码或其他的东西，只有开发者才能理解，不要显示。 把它们写到一个日志文件中，或者有一个可以按下的细节button来获取它们。
我假设你正在讨论在消息框或屏幕上向用户显示错误消息。
你的意思是面向用户或在pipe理员/开发人员的日志文件？
一般来说，我认为这些很重要：
- 时间戳
- 严重级别
- 出了什么问题
- 回答“我需要采取行动吗？”的问题 “如果是的话，有什么行动？”
- 开发级别的细节（不是显着的，如果面向用户的话）
- 一致的格式和条款
我认为所有这些都是重要的，但突出显示将取决于观众（如dmckee指出）。 另一个提示（一般来说）是回答5个W（谁，什么，…等）
我在一家软件安全公司工作，所以我的答案可能与上面的一些答案有很大的不同。
一个很好的用户面临的错误信息是：
在通用和特定之间进行平衡 – 您希望向用户提供足够的信息，以便他们能够纠正错误并继续前进，但请记住，攻击者可以使用这些相同的错误消息来攻击您的站点。 一个很好的例子就是一个login控件，在这个控件中返回一个错误消息“用户joe的密码不正确”或“用户joe在这个系统中不存在”，这告诉攻击者他们正在发现正确的用户。 当你既没有用户名也没有密码的时候，就是这场战斗的一半。
告诉用户出了什么问题 – 又是通用和特定之间的平衡。 用户从不需要查看ODBC错误消息，但是可能会帮助他们知道错误是您的错，而且他们应该在几分钟后再试一次。 告诉用户他们可以做些什么来帮助 – 如果您有一个后端日志logging系统（您应该）logging您认为有用的所有内容，然后生成一个您可以提供给用户的ID，以便他们可以致电或发送电子邮件给您并告诉你确切的repro步骤。 发生错误时，您也可以通过暴露错误提交表单来自动执行此操作。
保持一致 – 使用错误查找表来确保所有错误都是相同的（对于同样的问题），并且写得很好。 在生产软件中，错字，拼写错误和语法错误是不能容忍的。
对于最终用户：告诉用户该做什么。 如果用户改变了一些input值，在5分钟内重试或呼叫支持？
显然防错是最好的。 始终向用户提供足够的线索来成功完成任务（即在数据input字段中解释所需的格式）。 然而，“为了人类是错误的”，并且（通过将可用性原则应用于Web应用程序中的错误）宽恕是目标。
错误消息有三个基本function：
1.注意 – 首先要确保效果，用户必须看到它
- 红色）
- 字体（大小，重量）
- 位置（页面顶部，提示框）
- 重点（！符号，input框的轮廓）
- 一致性（在整个应用程序中使用类似的错误消息格式）
2.描述错误 – 告知用户出了什么问题
- 使用用户理解的简单语言
- 使用客观的声音，不要怪用户
- 简明扼要
3.build议恢复 – 给出有用的build议来解决错误并继续
- 保留迄今为止用户完成的任何事情
- 减less纠正它所需的工作
- 对于login的用户，允许超时重新validation
尽pipe如此，我还是希望能够编写更详细的内容，特别是通过错误消息的好坏来举例说明。
一个好的错误消息有三个部分：
- 问题 – 解释发生错误;
- 原因 – 解释导致问题的原因;
- 解决scheme – 解释如何解决这个问题。
如果您正在撰写或查看您的错误信息，请首先着重于写下这三点。 即使信息非常长，在第一次写作时不要担心。 您可以随时返回并简化它。
但事实恰恰相反。 把一个小小的信息塑造成一个清楚地解释问题，原因和解决问题的方法是很困难的。 你会不断地编辑你的想法，以确保消息保持小，并在某个时候，你会被阻止。 是的，我已经多次遇到这个问题，所以我知道这感觉有多难。
在你确认你的消息包含了所有这三个部分之后，再来看看它。 您需要编辑它以确保它：
- 以用户为中心 – 避免行话和话语，你的听众难以理解;
- 正如威廉·斯特朗克（William Strunk）所说的那样， 是直接的 ： 避免驯服，无色，犹豫和不交代的语言“;
- 省略不必要的字词 – 切割，切割，切割。
正如你所看到的，这个框架很简单，不需要太多的思考。
资料来源：
要编写出色的错误消息，您需要考虑每个受众。 一旦你了解了听众，devise错误信息就容易多了。
首先，对最终用户消息的要求：
- 想要执行任务
- 想知道解决scheme，而不是问题
- 实际上不希望看到或读取错误消息。
接下来，对支持技术人员消息的要求：
- 想要积极主动，不要被动
- 不想打“砖墙”问题
- 不想被消息充斥。
最后，支持开发人员消息的要求：
- 想要使用你的代码简单的心理模型
- 期望您的组件“只是工作”
- 想要有用的信息，当它不工作。
一个对最终用户来说非常糟糕的错误消息的示例是，“延迟caching与出站头文件相冲突”。 🙂
至于已经说过的话，我会补充一句：
- 不要显示任何可能存在安全风险的信息，如密码等。 这对于web应用来说尤其重要，如果这些东西不能通过反编译的话。
- 如果你还不是一个强迫性的文法和拼写问题，请使用所有用户可见的文本校对。
错误消息应该：
- 具体说明导致错误的原因。
- 提供纠正错误的build议。
- 不要使用混淆普通用户的词语。
从技术支持angular度来看，错误消息是唯一的也是很重要的。 如果用户可以通过六种不同的方式生成相同的“文件无法打开”错误，那么技术支持人员很难确定用户正在做什么。 所以，对于每一种不同types的错误，错误消息应该是唯一的，并且如果可能的话，提供错误代码或者数字，以便支持人们知道在哪里寻找问题。
我们发现，当错误消息包含错误代码时，它有助于技术支持。 当用户报告错误消息以支持人们时，他们经常混淆或错误地报告口头错误消息。 但是，如果邮件中包含错误号码，则他们非常善于报告确切的错误，例如“我尝试打印报告时发生了8512错误”。
如果可能的话，这也有助于logging错误。 很多时候，用户在尝试特定操作时会报告错误，但是他们不会记得错误是什么。 如果有技术支持人员可以查询错误日志，则可以更容易地确定问题。
通常值得指出这个问题的一个常见原因，因为这将在99.9％的错误情况下帮助用户。
例如，我们有两个初始化问题的方向。 一个捕获configurationexception，其中指出：
“发生了一个公认的exception，这可能是一个configuration问题”
另一个出乎意料：
“意外的错误发生了。”
然后根据设置（开关打开或closures），我们要么输出开发信息或更多的最终用户友好的信息ontop的。
错误消息是针对最终用户以及那些必须维护代码的人
首先为最终用户，告诉他们该怎么做。 这只需要input继续，再试一次，closures并重新启动，重新启动电脑。
其次，维护人员尽可能多地包含有关错误的信息。 从来没有太多。 我个人更喜欢这个日志文件，而不是一个错误消息。 更好的做法是为最终用户提供一种方式，通过电子邮件向用户发送来自应用程序的日志内容。
如果你可以告诉用户该怎么做，那么请考虑以编程方式进行。 在我看来，错误信息只有在程序不知道该怎么做时才会出现。 想想你为什么决定失败：也许没有责任去尝试恢复？ 也许用户可以做得更容易？ 也许用户必须决定采取哪种解决scheme？ 也许你认为它不应该发生（在这种情况下，不要忘记告诉用户联系支持人员或程序员）？
有一件事可能会损害我的神经系统，当一个错误消息使用单词OR。 “文件未find或没有权限或磁盘已满或您的狗头痛或头疼…”用户确实需要知道哪一个可能的错误原因发生。 程序员请避免ORs在错误信息。
不要将错误消息复制到代码的不同位置。 如果用户在程序中看到消息并发送反馈，那么幸运的是，您可以了解错误消息的含义。 不太幸运的情况是，你至less可以grep整个源代码，并find程序崩溃的地方。 如果你find同样的信息多个地方，你不能自己帮忙。
哦，不要忘记提及可能的后果：“松鼠预防系统退出了工作，任何存储在硬盘上的东西都可能被松鼠随机修改。 “松鼠预防系统停止工作，松鼠将被一般预防框架阻止。” 严重程度有所不同。
首先要记住，最终用户并不关心技术本质。 只有它是否有效。 当它不起作用时，他或她只关心它对正在做的事情的影响。 一个有用的错误信息应该集中在什么 ，而不是为什么 。
可以有几个不同的上下文来注意（虽然我确信这个问题已经被反复提及）：
1）如果我们正在谈论一个网站不得不提供一个“糟糕的，糟糕的事情发生”的消息，那么应该有简单的语言告诉用户发生错误，请再试一次，如果仍然有问题，请联系支持等等等等等等…
2）如果我们正在讨论为系统pipe理员和开发人员编写的代码抛出exception，那么这个问题就变得更多了：将exception的消息和堆栈跟踪logging到日志文件，电子邮件或事件中观看者，这样就可以按照不同的方式进行处理。
3）如果我们正在谈论写一个exception的消息，那么我的build议是要清楚地注意到什么样的错误条件得到满足，例如是否存在空引用，哪里不应该或者是否有更糟的文件，如应该存在缺失，以及错误的严重程度，例如应用程序是否继续运行，或者是否应该在这种情况下退出到错误页面。
从用户的angular度来看。
