Under what circumstances should error messages be presented to the user?

Question

Should error messages ever be presented to an end user and if so what rules or advice should you have about what should be in them?

Answer 1

Yes

Error messages (when needed) should be presented to the user.

What rules or advice should you have about what should be in them?

Present an error to the user when:

1. What they need to know. Don't include errors that they won't understand. "SQL connection failed" is not a good error. "There was an error saving your appointment." is much better.

2. They can fix it. "You didn't include a date for your appointment." is a solvable error.

3. They expect something to happen. Don't fail silently when they are expecting something. Acknowledge the user action at the very least, and at best provide an appropriate error.

Answer 2

Error messages should be presented to the user if:

• The user initiated the error condition (for example, "you did not include a password on the input form")
• The user can do something about the error condition (for example, "there is no network connection")
• A critical error has occurred that the application cannot recover from (for example, "the database is corrupt")

Answer 3

You should present error messages to the user if he/she can do something about it. Either by allowing sending a bug report before quitting, or by deciding the way to go after a specific kind of error, one that have different possible resolutions that the user knows better the context.

Don't break the user experience if you can/until you have to.

Answer 4

I think it's quite important to show some kind of user-level message when exceptions raices up, this way they have something to report to a supervisor, the dev team could have some more information and bug tracking could be done a lot faster.

The detail on the message should depend on the environment the app is running, from totally verbose in dev env to "There was a problem saving a profile, please contact your supervisor" on a prod env.

Answer 5

Errors should be presented to the user when he/she can do something about, along with suggested course of action even if it is to be "call this number" or "click on this link to report the issue".

Never present the user with an error that is meaningless or does not offer a course of action.

Answer 6

I like to be able to tell users if there is a problem with their environment or configuration that is going to stop the software from working and if possible suggest how to address it. You can't always know why you will fail, but environment problems are one of the more common things you run into with PCs.

Users should always know somehow if there is a problem that means they can't do the task they are trying to do. You might not term it in the same way as you would for your own use, but you need to let them know that something has happened. Ideally you want to offer the facility to automatically notify the developer that the problem has occurred as well.

The third situation is if they have made a mistake - left a field empty, put the wrong format of data into a field and so on - that they can rectify for themselves.

The error messages always need to make it clear what has happened and what the user can do to sort it, or what they need to do to make the best of it.

Answer 7

Yes, errors should be reported. Consider the situation where the user inputs the wrong password and was bot able to log in. Imagine what if the application instead of giving error, "Wrong password or username" simply gets back to the original password asking screen. The user will certainly get confused saying "Huh.., what did just happen?".
Report every possible error that can occur and which the user can understand. Also think about what the information should be displayed. Think about the support. If the user after getting error, comes back asking why the error, then the support should be able to answer. For this there should be enough information in the error. This information need not be shown to the user, but must be somewhere in the logs.

Answer 8

You should always present a problem to a user in easily understandable words based on information provided by the underlying architecture.

"The file could not be saved to this location. You must save it to another location".

You should also allow for the user to access the full error messages and forward them to the development team, but do not do it up front. This can be very helpful in a phone support situation.

Answer 9

My advice, code-wise, is to never swallow errors/exceptions, and never catch general exceptions. Catch only specific ones that you know are possible (for example, array "out of bounds" errors) and handle them accordingly, giving the user some type of feedback as per @Josh K's answer.

However, there are times where it's probably better to swallow errors. Something stupid like a user opens a file used by your app and prematurely kills the program, causing some type of file handling error -- your application is closing, it offers no benefit to deal with it. In this case, you still shouldn't just ignore it, just dump the problem to an error log and if the user has a problem, you can refer to that.

That's also another point: record your application's errors with an error log. Fairly simple to do and could save you dozens of headaches in the future. Just take precautions to make sure it doesn't balloon up to 20 GB in size.