Site News for 8/26/07 through 9/1/07Introduction to the ErrorProvider Component

5 Elements of Style For Error Messages

September 3rd, 2007

I'm so stupid! I just don't understand this computerIt’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?

error message example 1

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:

error message example 2

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:

error message example 3

But, instead, use something like this:

error message example 4

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:

error message example 5

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:

error message example 6

The rules of presenting a polite error message are simple:

  1. No shouting at the user with ALL CAPS.
  2. Avoid using pejorative terms like fatal, illegal, invalid.
  3. If you must use icons, use matching standard Windows icons and not a skull and crossbones or other intimidating graphics.
  4. Avoid using cutesy error sounds like a ’raspberry’ (I actually heard this on a point-of-sale app in a convenience store!)
  5. The message should not blame the user for the problem but it should help the user seek a solution to it.
  6. 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.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Entry Filed under: Tip Sheets

Rate This Article:

Not That GoodCould Be BetterOKGoodGreat (10 votes, average: 4.4 out of 5)
Loading ... Loading ...

8 Comments Add your own

  • 1. Andre Perusse  |  September 5th, 2007 at 7:50 am

    Very good advice. I have also read that presenting errors in a modal dialog is something programmers should try to avoid, since it “jolts” the user out of the main interface of the application. Something to think about, anyway.

  • 2. jfrankcarr  |  September 5th, 2007 at 8:26 am

    Thanks Andre,

    I agree that a modal dialog error message should be reserved for the most critical errors. It shouldn’t be used for simply telling the user that they entered the wrong information or didn’t fill in a required field.

    For this kind of user entry management in VB.NET apps I recommend using the ErrorProvider component as I described in the next article. For web based ASP.NET or LAMP apps, I recommend using AJAX techniques to produce similar results.

  • 3. John  |  September 10th, 2007 at 4:38 am

    Every error message should state what happened, why it happened, and how (or who) to fix it.

  • 4. jfrankcarr  |  September 10th, 2007 at 8:25 am

    Thanks for your comment, John

    What inspired me to write this article were the poor error messages I see in a vendor provided program at work. Their error messages do like you said, showing the what, why and how/who, but are ultimately next to useless because they’re so user unfriendly and packed with too much information. My take is that they should have greatly simplified the error information they were displaying to the non-technical users and logged the error details to disk where they could be reviewed and passed on by the IT staff.

    It’s important to remember that the UI for error messages should have the same considerations for the user as the rest of your UI does.

  • 5. Donn Felker  |  September 18th, 2007 at 4:33 pm

    I feel the exact same way as you do in this post.

    If you need to throw an exception, put meaningful text in the exception, and then put the original exception into the innerexecption property!

    Its not that hard! Or even better, use some type of ExceptionHandler framework like Enterprise LIbrary so you can log them to different areas. But it still boils down to being a defensive coder and writing proper unit tests to simulate what happens if hte network is not available. Etc etc etc. I could go on forever about this.

    Good post.

  • 6. jfrankcarr  |  September 18th, 2007 at 7:39 pm

    Hi Donn

    Thanks for commenting.

    I found the MS Enterprise Library to be overkill for my projects and I ended up writing my own streamlined error logging and reporting components. I think the Libraries work best in larger projects than small to mid-sized ones.

  • 7. lillbra » Blog Arch&hellip  |  September 21st, 2007 at 1:08 am

    [...] att lindra användarens plåga då ett fel uppstår. J. Frank Carr listar de viktigaste punkterna att tänka på när man skapar felmeddelanden (via, fritt översatt av [...]

  • 8. Dan Parker  |  March 11th, 2009 at 1:43 pm

    I got the error Message When I close Datagrid in VB.Net .
    “There is no row at position -1.”
    Please let me have solution.

Leave a Comment


Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed

Visit Me At My New Site, Programming In C#

Most Popular Articles

Highest Rated Articles


Most Recent Articles


 Subscribe in a reader

To subscribe by e-mail
Enter your address here

Delivered by FeedBurner

VB Opportunities