错误处理：是否显示错误消息？

Question

通常，在软件设计中，当资源（例如数据库或文件）出现问题或错误时，首选哪个选项？

1. 显示错误消息
2. 不显示错误消息，并表现为资源为空（例如，不填充GUI组件）]

例如，如果用户看到他们抱怨的空DataGrid，或者是否应该出现错误消息？哪个更好？

Answer 1

我不认为这是一个/或。此外，我们需要考虑系统的所有“用户”。

首先考虑用户界面。让我们考虑一个人为的一般情况：您通过调用服务来填充UI，该服务又使用几个数据库（例如“当前数据”和“历史数据”）数据库。

至少有这些可能性：

• 一切正常，检索数据
• 一切正常，但碰巧没有这个特定查询的数据
• 无法联系到服务
• 调用服务，但一个数据库已关闭
• 调用服务，但两个数据库都已关闭

然后还要考虑应用程序的语义。如果无法检索到所有数据，您的applciation是否会以“降级”模式进行？例如，我们无法查询历史记录，但这并不能阻止我们创建新项目。

现在也考虑这里的角色。使用用户界面的人，还有需要了解和解决问题的支持和维护人员。

我的一般规则：

1. 首次故障数据捕获：无论哪个组件首先检测到错误，都应详细记录。因此，服务，数据库关闭服务应该记录问题。服务下来，UI应该记录问题。此日志应该是针对支持角色的技术记录。
2. UI应该是宽容的：如果可能的话，在降级模式下运行。因此，如果服务已关闭，但（例如）本地工作可能会出现空屏幕并继续。但是......
3. 始终指出问题：“此查询无数据”和“数据库不可用”情况都可能导致空屏幕。用户需要知道显示器的状态，是显示完整信息，部分信息（例如，因为一个DB是关闭的）还是没有可用信息（例如，服务或两者都是dbs）。所以在屏幕的某个地方有一个“状态”字段。提供诸如
之类的消息

  

Historica数据目前无法使用

或

  

检索时出现问题   信息，如果这些仍然存在请   联系支持......

Answer 2

每个选项都有一些陷阱

显示错误消息

当您的应用程序处于测试阶段或公开测试时，这特别有用。此外，当客户遇到错误时，他或她可以复制详细信息并转发给您。

然而，有时这个错误消息变得非常难看（调用堆栈等等 - 还记得ASP.NET吗？）它变得如此之大，以至于客户端很难复制细节。

不显示错误消息，并表现得好像没有发生任何事情=）

当您不希望错误消息来处理软件UI设计时，这非常有用。但需要提醒的是，当客户端无法区分实际错误或GUI上的任何错误时，它变得困难且容易出错。错误仍然存​​在，没有任何问题得到解决。

我的立场

充分利用这两个世界。事实上，大多数现代应用程序如何拥有非常好的错误处理流程。我将以Mozilla Firefox 3为例。

1. 发生致命错误，Firefox崩溃
2. 捕获错误并将其作为错误报告的形式存储到文件中
3. 错误报告应用程序弹出向用户道歉
4. 询问用户是否要将错误报告发送给软件开发团队
5. 然后询问用户是否要重新启动应用程序

或者如果错误是警告或严重程度较低：
显示一个简单的错误代码，并告诉用户该操作存在错误。类似于：“RequestSalary（）第2行的错误123”

Answer 3

我通常使用的做法是：

1. 如果由于用户错误而未发生错误，则应尝试安静地处理错误。
2. 如果由于某些外部问题（例如没有互联网连接）而发生错误，那么您应该提醒用户。

Answer 4

IMO你应该显示一条消息（尽管用户友好，而不是像“java.io.IOException：Connection timed out”。）你可以有一个消息框告诉用户在获取数据时发生错误提供有用的提示，如：一段时间后尝试，检查网络电缆等。 还允许用户向您报告该错误（错误报告构建到应用程序中），它将向您发送实际错误和堆栈跟踪。