0

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

  1. 显示错误消息
  2. 不要显示错误消息并表现得好像资源是空的（例如，不要填充 GUI 组件）]

例如，用户应该看到他们抱怨的空 DataGrid，还是应该有错误消息？哪个更好？

4

4 回答 4

2

我不认为这是非此即彼的。此外，我们需要考虑系统的所有“用户”。

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

至少有以下几种可能：

  • 一切正常，检索数据
  • 一切正常，但碰巧没有此特定查询的数据
  • 无法访问服务
  • 服务被调用，但一个数据库已关闭
  • 调用了服务，但两个数据库都已关闭

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

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

我的一般规则：

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

Historica 数据目前不可用

或者

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

于 2010-07-22T05:29:11.983 回答
1

每个选项都有一些陷阱

显示错误信息

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

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

不要显示错误消息并表现得好像什么都没发生 =)

当您不希望错误消息影响您的软件 UI 设计时，这很有用。但请注意，当客户端无法区分实际错误或 GUI 上什么都没有时，这会变得困难且容易出错。错误仍然存​​在，没有任何东西得到修复。

我的立场

两全其美。事实上大多数现代应用程序都有一个非常好的错误处理过程。我将以 Mozilla Firefox 3 为例。

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

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

于 2010-07-22T03:55:21.273 回答
0

我通常使用的做法是：

  1. 如果错误不是由于用户错误而发生的，那么您应该尝试安静地处理错误。
  2. 如果由于某些外部问题（例如没有互联网连接）而发生错误，那么您应该提醒用户。
于 2010-07-22T03:51:48.167 回答
0

IMO 您应该显示一条消息（尽管是一条用户友好的消息，而不是类似“java.io.IOException：连接超时”之类的消息。）您可以有一个消息框告诉用户在获取数据时发生错误并提供有用的提示喜欢：一段时间后尝试，检查网络电缆等。还允许用户向您报告该错误（错误报告内置到应用程序中），这将向您发送实际错误和堆栈跟踪。

于 2010-07-22T03:53:24.287 回答