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?
asked Dec 23, 2010 at 16:03
-
1Your app better tells me when something doesn't work rather than pretending everything went fine (think of saving - "I saved you important stuff (actually, the harddrive is on fire, but I don't want to annoy you)!")... so yes, the user should know about errors.– user7043Dec 23, 2010 at 16:05
-
Two links I find helpful on the general topic but not exact answers to your question, so here as a comment... blogs.msdn.com/b/oldnewthing/archive/2006/11/01/922449.aspx and blogs.msdn.com/b/ericlippert/archive/2008/09/10/…– MIADec 23, 2010 at 16:31
Add a comment
|
9 Answers
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:
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.
They can fix it. "You didn't include a date for your appointment." is a solvable error.
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.
-
should you ever include any more technical details that might help when the error is reported? E.g. "There was an error saving your appointment. (SQL connection failed)"?– ArmandDec 23, 2010 at 17:53
-
1@Alison maybe an error code along with the message so, in the case of support, there's less to be lost in translation from the user? Dec 23, 2010 at 18:21
-
1@Alison: Think of the "Details >>" or "(+) Details" button on many error message dialog boxes. The technical details are hidden by default, and can be revealed when needed. Dec 23, 2010 at 18:37
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")
-
@Justin Can you give examples of when should the error not be presented ?– GauravDec 23, 2010 at 16:30
-
1If a network failure occurs the user does not need to know if the system can work around the failure or recover from it. For example, a message delivery error occurs - there is no need to alert the user because we can retry the message. But if 10 failures occur then we give up, so we need to notify the user somehow. Of course they may not be able to do anything about it either, so we may just change an icon's status to red instead of throwing up a dialog to tell them about it. Dec 23, 2010 at 16:33
-
@Justin Thanks for the example, basically the last point becomes if the application can not recover from (or work around) error– GauravDec 23, 2010 at 16:44
-
Yes, that is probably a better way to put it. Thanks for your feedback. Dec 23, 2010 at 16:47
-
3I wouldn't display "the database is corrupt." Many non-technical people do not know what a "database" is or how it could be "corrupt". With critical errors like that, there needs to be a way a support team is notified with technical details, and the user should just see a message stating there was a problem with whatever operation they were trying to attempt; ie: "There was a problem trying to save your changes. Your support team was alerted, and given the details they need to help solve this issue." You should also provide any workarounds in the message, if possible. Dec 23, 2010 at 17:09
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.
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.
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.
-
I guess the downvoter is one of those that likes to show the users cryptic messages - "Not enough memory to display this dialog." or "Error Keyboard not found. Press F1 to continue." Dec 23, 2010 at 16:21
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.
answered Dec 23, 2010 at 16:15
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.
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.
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.
