September 3rd, 2007
It’s a fact of programming life that errors will happen in our programs once users get ahold of our programs. Some of these may be due to programming bugs, some due to operating system or network access problems, or they may be due to user mistakes. In all these cases our programs should handle these problems gracefully. However we often find ourselves shortcutting error handling and messaging and playing a ‘blame game’ with the user or presenting cryptic error messages.
1. Avoid the Error
The secret of the sword is never to unsheathe the sword. - Taisen Deshimaru
We’ll begin by taking a Zen like approach by saying the best error is no error. This means that we should make every effort to avoid errors we can avoid. For example, before we open a file we should check to see if the file actually exists or if we use String.SubString we should confirm that the length will handle the call. If we pass these errors on to the user interface we’re really allowing two bugs into our program. First, we’re introducing a performance bug by processing an unneeded exception and, secondly, we’re failing to properly validate user input.
2. Do Not Use the Default .NET Exception Text
Have you used something like this in one of your applications?
This kind of error message, while it may be helpful in debugging, is scary to users. You shouldn’t allow this kind of error message become visible to users in a fully released product. If you do include such an error message in a beta release, make sure your test users know that this message is intended for you, not them, and that they know how to copy it to an email for you. You could make it clearer to them by adding text, like so:
Better yet, simply log the full exception message to disk and simply let the user know that the program failed without giving confusing and unnecessary details.
3. Avoid Vague and Generalized Messages
If you’re going to go to the trouble of presenting an error message to the user, make it one that precisely defines the problem, not one that doesn’t say anything meaningful. For example, don’t use something like this:
But, instead, use something like this:
4. Help The User Solve The Problem
Error messages should help the user solve the problem. For example, in the error message just above, it tells the user to contact support since this is the best course of action for them to take.
In VB.NET another way we have to help the user solve the problem is to not use message boxes at all but, instead, use the ErrorProvider component. This component, which I’ll cover in depth in a future article, allows you to check user input and provide immediate feedback through an icon and tooltip rather than a show stopping modal messagebox dialog.
Another way our programs can help a user solve problems is to use auto-suggestion, much like Google does in its searches:
5. Don’t Blame The User
This should almost go without saying but your error messages should not place the blame on the user. Instead they should be polite and non-intimidating. For example, you don’t want to show a user an error message like this:
The rules of presenting a polite error message are simple:
- No shouting at the user with ALL CAPS.
- Avoid using pejorative terms like fatal, illegal, invalid.
- If you must use icons, use matching standard Windows icons and not a skull and crossbones or other intimidating graphics.
- Avoid using cutesy error sounds like a ’raspberry’ (I actually heard this on a point-of-sale app in a convenience store!)
- The message should not blame the user for the problem but it should help the user seek a solution to it.
- The message should be grammatically correct and spell checked (Can you spot this mistake in the example error dialogs in this article?)
I hope this article has been informative and helpful to you. Let me know if you liked it or not by leaving me a comment, using the Contact Me button, or using the rating star system. Or, If you have anything to add, a question, or a funny/sad error message anecdote, please leave a comment.
Entry Filed under: Tip Sheets
Rate This Article: