Home » General QA Stuff » Oops!…Now What?

Oops!…Now What?

Start here


If there is one area that seems to be consistently over looked during the software design process, it’s Error Handling.

A well-designed application will detect and report any error to the user long before it becomes a major issue – like trying to store bad data in the database.  Don’t rely on just reporting system error messages, or the dreaded yellow screen in ASP.NET, to let the user know they messed up.  In fact – never let developers do that!  Good error handling will let the user know, in a friendly manner, that they messed up and will guide them towards an appropriate resolution.  Too many times I’ve seen system error messages that went directly to the UI.  Not only does it completely, and sometimes unnecessarily, terrify the user, it doesn’t tell them what they did wrong or how to resolve it.  OK – it does, but usually in developer-speak.  Something like “AccountNumber is NaN”.  Huh?

Typically, if we don’t tell the developer how to handle and report errors, they will be left to their own devices.  The results: inconsistency – the same type of error is reported differently in different areas of the application.  Omission – errors may be missed (until the database crashes).  Errors are reported in developer-speak or system messages.  I even had an application developed off-shore report an error in Chinese.  The text was red so I assumed I had messed up.

I like to focus on errors and error handling early.  Hopefully in the design/requirements process.  I discreetly remind them that if they ignore me now, they do so at their own peril later on.  I make a note and we move on.  By the way, when you do find the error, try to resist the “I told you so” comment.  Gloat in private.

There are lots of ways to handle and report errors.  Some of them work well.  Others, not so well.  Here are some of the things I typically look for:

 – Consistency:  The same type of error gets the same message no matter where it occurs in the application.  Same error level, text, icon, color, etc.  And the error always appears in the same place (top of the page, next to the data field, etc.)
 – Obvious:  Don’t make me look for it.  Make it highly visible.  Don’t make me scroll to find it.  I hate it when an application tells me there is an error but doesn’t show me where.  Or worse, just reloads the page and makes me guess what happened.
 – Feedback:  If you can, let the user know not only what they did wrong, but how to fix it.  Exception:  you can be vague on log on pages.  You don’t want to guide a potential hacker to the correct solution.
 – Colors:  Different colors mean different things.  Red=danger, yellow=caution, green=good to go, blue =information.  Use a color appropriate to the error.  Don’t tell me the system is about to crash in blue.
 – Icons:  Again, like colors, if you use them, use an icon appropriate for the error.  Typical icons I’ve seen: stop signs, caution signs, question marks, check marks.  If you use color as well, follow the color rules above.  If everything worked, don’t show the user a red check mark.
 – Avoid flashing things or sounds:  Unless you are about to detonate a nuclear missile.  Then its OK.
 – Watch the text:  Don’t be judgmental or long-winded.  Quick, short, and to the point.
 Best Practices
Once again, my apologies to the Context-Driven folks – some Best Practices.  No wait – I’m not apologizing – I stand by my use of “Best Practices”!   Here are some things I’ve seen in the past and really like:
 – Combine colors with icons.  For example, icon,  text or background colors fit the error level

 – Use Regular Expressions: Or tell developers to use them.   A RegEx is a great way to detect errors.  Store them in a database table and call them as needed.  Helps to insure consistency.  There are a bunch of regular expressions already written for them on the Internet.  There are also some great RegEx checkers.
 – Message Catalog:  Create a table in the database to store all messages reported to the user.  You can also include the message level:  Informational, Caution, Danger, etc.  Don’t forget positive messages such as:  “Record Updated”, “Mail Sent”, etc.  The Message Catalog comes in handy if you ever need to localize your application – trust me!
 – Write an Error Handling Guide or Specification:  Hopefully before the first line of code is ever written.
 Never over-estimate your user.  They will mess up !  Be one step ahead of them.  Think “Defect Prevention”!



  1. “Different colors mean different things.” … “Combine colors with icons.”

    Use these best practices with caution if you need to consider color-blind users.

  2. Cap'n Dave says:

    I couldn’t agree more Joe! That’s why for a general use application, I do not rely on color alone. Combining icons with color and text is a typically a good compromise. Now if your target users are color-blind, you may want to consider other options as well. The point I was trying to get across is that some colors, (especially red, yellow, and green) through common usage, have come to mean certain things. Don’t send mixed and/or confusing messages.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: