应该向用户显示多少有关错误的信息？

应用程序总是会抛出错误。如果发生此类错误，则应通知用户，因为他要求应用程序执行的操作未成功。

但是，应该向用户提供多少信息？我认为我们大多数人都同意不显示堆栈跟踪（堆栈跟踪是否应该出现在向用户显示的错误消息中？），但是我找不到有关其余错误内容或向错误显示的内容的问题。用户。

例如，支持异常的语言（.net，java）具有共享的异常类型（发生异常的位置）以及与异常一起传递的澄清消息。还应该对用户隐藏吗？还是我们应该显示这个？还是应该显示一般性消息？还是应该根据潜在的异常是显示大量消息之一？

向用户显示什么。还应该对用户隐藏吗？

您向用户显示对他们可采取的措施。

例如，如果您由于某些空指针异常以及比用户错误更多的错误而导致错误，则您不需要完整的解释，因为它们不能做任何不同的事情。

还是我们应该显示这个？还是应该显示一般性消息？

对于大多数用户而言，将异常显示为主要错误消息的内容是毫无意义的。也许如果您的目标用户群是开发人员，则可以始终将信息显示为完整错误（也许您有一个用于自动测试的内部应用程序）。但是通常，即使有了这些知识，用户也无法做任何不同的事情。

我们是否应该根据潜在异常是显示大量消息之一？

最佳策略是执行以下操作：

• 将错误解释为对用户有意义的文本。
  • 部分原因是“用户可以做些什么？”
  • 如果他们不能做任何其他事情，请说“发生了意外错误”。
• 添加“可选”详细错误描述
• 允许用户提交错误报告（或根据用户群自动执行）

例

1. 它显示“这里发生了什么”（意外错误）
2. 告诉用户该怎么做（重新打开Mail，甚至包括执行此操作的快捷方式）
3. 如果有人好奇地看到完整的技术错误，也有一个“查看详细信息”
4. 提供通知，报告错误报告已提交（请参见下文）

请注意，在某些情况下，您可能希望使错误报告为手动还是自动。

这取决于用户是谁，以及他们可以如何使用信息。

通常，尝试仅向他们显示有关他们可以解决的事情的有用信息。顶部带有正则表达式错误的40行堆栈跟踪不是很有用。一条更好的消息是说Date必须格式化为“ yyyy-mm-dd”。除此之外，用户可能不知道如何响应该错误，然后他们可能不希望使用您的应用程序，因为这会导致更多隐秘且令人恐惧的错误（是的，非技术用户有时会被堆栈吓到痕迹）。这可能对业务不利。

对于其他开发人员使用的内部应用程序，除了显示更有用的内容外，我对显示堆栈跟踪也更加放松，因为我知道用户可以处理查看堆栈跟踪，并且可能会知道该怎么做。

对于非技术用户，我认为唯一可以向他们显示堆栈跟踪的情况是在严重错误情况下，您需要它来解决问题，然后要求他们复制并粘贴堆栈跟踪并将其发送对您来说，虽然确实更好的方法是要求他们发送日志文件，或者更好的方法是让应用程序在询问用户共享文件的权限后将日志文件发送给开发人员。

发送给用户的消息应与创建新的异常以同样的方式对待-您可以提供他们决定操作的信息。

这当然取决于您的应用程序和用户群，但这应该是您的指导原则—您的意图应该是为“调用者”提供所需的信息，以确定他们可以采取哪些措施来成功执行所需的操作。如果是简单的事情，例如对文件的访问错误，请提供文件路径和无法访问的消息。如果是空指针异常，则仅给出一般错误消息。

当然，“无法执行所需的操作”消息的数量将超过用户可以实际修复的消息，但这只是生活而已-大多数例外是因为我们犯了一个错误，而不是因为用户设置了环境错误地。

这是一个共同的主题：

在显示程序员，开发人员，测试人员等更高级的用户可以使用的信息的同时，如何帮助不了解信息的人/计算机不识字。

我认为答案是两者都做！

顺序很重要，但我建议您有：

• 发生了什么。
• 现在做什么
• 技术细节

技术细节是报告问题时具有高级订单或普通用户信息的部分

您要显示的内容取决于您为搞砸而感到羞耻。

关键是要尽快，顺利地获得技术支持失败的详细信息。这可能意味着您将包含终止错误的堆栈跟踪的日志文件自动发送回了家，或者您请用户单击一个将启动传输的按钮。如果没有互联网连接，也许通过USB记忆棒。

我喜欢接受的答案背后的理由，但我必须尊重我至少不同意将信息限制为“可操作”内容的解释。我想比“意外错误”多得多一点。

当然，我有点计算机知识，并且有这种偏见，但是我认为这不是一个特别偏见的观点。因为我可以通过将这种思维方式应用于航空等我所缺乏专业知识的领域来尽力消除这种偏见。

虽然我对航空知之甚少，但说我的航班延误或取消了，工作人员告诉我的唯一一件事是：“我们发生了意外错误。请等待3个小时再进行一次飞行。” 在这种情况下，您至少会发现我更心怀不满，因为尽管这两种方式并没有真正影响我的行动，但我只想稍微了解一下我为什么这样给付费客户带来不便。

如果他们只是说“我们遇到了动荡的天气”或“我们在前一次飞行中遇到了医疗紧急情况”，或设备出现故障或其他原因，这足以让我同情除“意外错误”之外，坐在那里，等待下一个航班3个小时多一点。实际上，我什至可能更喜欢发生一些“技术错误”，而不是“意料之外的错误”，例如：“好吧，从嘴里说出来的话会进入我的耳朵，但不会到达中央处理器。但是我现在知道有某种东西问题，我去喝杯咖啡，坐在那儿！希望你们能用那个东西解决问题！”

而且通常在异常处理方面，我想您通常具有足够的catch现场事件基本信息，即使您想隐藏异常的更多技术细节，例如：

try
{
     load_file(file_name);
}
catch (const exception& ex)
{
     exception_dialog("Failed to load file: '{1}'.", file_name);
}

而且，这甚至没有显示可能与异常相关的非常技术性的信息，但是，它告诉我们的不仅仅是“意外错误”。它至少提供了上下文“什么/在哪里/何时”，即使它没有说“为什么/如何”。我认为至少对于基本信息水平的需求并没有因为我的计算机熟练程度而特别有偏见。

其余的可能非常针对您的客户和特定需求。但是，我的呼吁至少要比“意外错误”少得多。