Title: A quick note on error messages

I went to a local museum the other day and when the attendant scanned by membership card his computer said:

Object not set to a reference of an object.

Because we're programmers, you and I know what that means (more or less), but the poor attendant hasn't got a clue. The message may as well have said:

There's an error and I'm not going to tell you what went wrong or what to do about it! Bwah, hah, hah!

Of course the attendant had seen this message before, probably hundreds of times, so he knew what to do and scanned my membership card again at a different speed holding it slightly differently. It worked the second time.

The point of the story is that you should never display an error message like this one to a user. They don't know what it means and don't know how to try to fix the problem. You may as well just insult the user and get it over with.

Whenever I see a message like this in an application I'm using, I think, "What a piece of garbage. A beginning programmer could have anticipated this error and displayed a better message than this." Do you really want the user to think of your program as a piece of garbage (or worse) every time they use it?

In my trip, it was obvious that this error occurs frequently so displaying such a bad message is even less forgivable.

The moral is, you should always catch errors (with a try-catch block in C#) and display something meaningful to the user. Even if you can't really tell specifically what went wrong, give the user a general idea of what went wrong. If possible, include a suggestion of something to try that might fix it. In this case a much better message would be:

Error scanning membership card. Please try again or enter the membership number manually.

See? Even not knowing exactly what was going wrong in the software, I can come up with a meaningful and constructive error message.

Download the example to experiment with it and to see additional details.