Error handling: show error message or not?

Question

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?

1. Show an error message
2. 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?

Answer 1

The practice I usualy use is:

1. If the error didn't happen due to user error, then you should try to handle the error quietly.
2. If the error occurred because of some external problem (such as no internet connection) then you should alert the user.

Answer 2

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.

Answer 3

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.

1. A deadly error occurred and Firefox crashes
2. Error is captured and stored into a file as a form of error report
3. Error Reporting Application pops up apologizing to the user
4. Ask the user if the user want to send the error report to the software dev team
5. Then ask the user if want to restart the application

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"

Answer 4

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:

• It all works, data is retrieved
• It all works but as it happens there's no data for this particular query
• Can't reach the service
• Service is invoked, but one database is down
• Service is invoked, but both databases are down

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:

1. First Failure Data capture: Whichever component first detects an error should log it in some detail. So, service up, database down the service should log the problem. Service down, the UI should log the problem. This log should be a technical record targeting the support roles.
2. UIs should be tolerant: if at all possible run in a degraded mode. So if the service is down but (for example) local working is possible put up an empty screen and continue. BUT ...
3. Always indicate a problem: The "no data for this query" and "databases unavailable" cases may both result in an empty screen. The user needs to know the status of the display, is it showing complete information, partial information (eg. because one DB is down) or is no information available (eg. service or both dbs down). So have a "Status" field somewhere on the screen. Giving messages such as

Historica Data not currently available

or

There are problems retrieveing information, if these persist please contact support ...