错误处理：是否显示错误消息？
一般来说，在软件设计中，当数据库或文件等资源出现问题或错误时，首选以下哪个选项？
- 显示错误消息
- 不要显示错误消息，并且表现得好像资源为空（例如，不填充 GUI 组件）]
例如，如果用户在抱怨后看到一个空的 DataGrid，或者应该出现错误信息？哪个更好？
Generally, in software design, which of the options below is preferred when there is a problem or error with a resource such as a database or file?
- Show an error message
- Do not show an error message and act as though the resource was empty (eg. do not populate a GUI component)]
For example, should the user see an empty DataGrid following which they complain, or should there be an error message? Which is better?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不认为这是一个非此即彼的问题。另外，我们需要考虑系统的所有“用户”。
首先考虑用户界面。让我们考虑一个人为的一般情况：您通过调用一个服务来填充 UI，该服务又使用几个数据库（例如“当前数据”和“历史数据”）数据库。
至少存在以下可能性：
还要考虑应用程序的语义。如果无法检索所有数据，您的应用程序能否以“降级”模式继续运行？例如，我们无法查询历史记录，但这并不妨碍我们创建新项目。
现在还要考虑这里的角色。有使用 UI 的人员，也有需要了解和解决问题的支持和维护人员。
我的一般规则：
或
I don't see this as an either/or. Also, we need to consider all "users" of the system.
First consider the UI. Let's consider a contrived general case: you are populating a UI by calling a service which in turn uses a couple of of databases (for example a "current data" and an "historic data") database.
There are at least these possibilities:
Then also consider your application's semantics. Can your applciation procede in a "degraded" mode if all the data cannot be retrieved? For example, we can't query the history but that doesn't stop us creating a new item.,
Now also consider the roles here. There's the person using the UI, there's also support and maintenance people who need to know about and fix problems.
My general rules:
or
每个选项都有一些陷阱
显示错误消息
当您的应用程序处于测试阶段或公共测试时，这特别有用。此外，当客户遇到错误时，他或她可以复制详细信息并发送给您。
然而，有时此错误消息会变得非常难看（调用堆栈等 - 还记得 ASP.NET 吗？），并且它变得如此之大，以至于客户端很难复制详细信息。
不要显示错误消息并表现得好像什么都没发生一样 =)
当您不希望错误消息影响您的软件 UI 设计时，这非常有用。但请注意，当客户端无法区分实际错误或 GUI 上实际上没有任何错误时，这会变得很困难并且更容易出错。错误仍然存在，没有任何内容得到修复。
我的立场
两全其美。事实上，大多数现代应用程序都有一个非常好的错误处理过程。我以 Mozilla Firefox 3 为例。
或者错误是否是警告或较轻的严重性：
显示一个简单的错误代码并告诉用户该操作存在错误。类似于：“RequestSalary() 第 2 行出现错误 123”
There are some pitfalls to each of the options
Showing error message
This is specially helpful when your application is in testing stage or public testing. Also when clients meets an error, he or she can copy down the details and forward to you.
However sometimes this error message gets very ugly (call stacks and so on - remember ASP.NET?) and it becomes so large that it becomes difficult for clients to copy down the details.
Do not show error message and act as though nothing happened =)
This is useful when you don't want error messages to cog up your software UI design. But be reminded that it becomes difficult and further error prone when clients can't differentiate between an actual error, or really nothing on the GUI. The error stays there and nothing gets fixed.
My stand
Get the best of both worlds. In fact most modern applications how have a very good error handling process. I'll take the example of Mozilla Firefox 3.
Or if the error is a warning or of lesser severity:
Show a simple error code and tell the user that there's the error with that action. Something like: "Error 123 at RequestSalary() Line 2"
我通常使用的做法是：
The practice I usualy use is:
在我看来，您应该显示一条消息（尽管是一条用户友好的消息，而不是类似“java.io.IOException：连接超时”之类的消息。）您可以有一个消息框，告诉用户在获取数据时发生错误并提供有用的提示比如：过一段时间再尝试，检查网线等。
还允许用户向您报告该错误（应用程序中内置错误报告），这将向您发送实际的错误和堆栈跟踪。
IMO you should show a message (albeit a user friendly one and not something like "java.io.IOException: Connection timed out".) You could have a message box telling the user that an error occured while getting the data and provide helpful tips like: Trying after some time, check network cable, etc.
Also allow user to report that error to you (error reporting build into the app) that will send you the actual error and stack trace.