I thought it was about time I refreshed my rules for what good error messages are:
- Consistant. This could be visually consistant in the case of message boxes, or if they are being logged to a file or database table then being consistant helps them also to be machine readable.
- Informative. Consider ADO & ADO.Net's old "General Network Error" as the best example of how not to do errors. The key point here is the message should first say:
- what did not work correctly, and
- what you should do next to fix it
Stack traces etc should come later.
- Appropriate. Consider the audience of your application. They are the audience for your erorrs too! The level of detail I expect in an error from SQL Server is completely different to the kind error I expect from iTunes.
- Respect my attention span. 750 Event Log messages a day means I won't look at them. Once a quater means I won't look at them. The latter case should be emailed. The former case probabbly should be replaced with one critical failure message
- Respect my privacy. Passwords, maybe even user names, or anything that is sensative in the context of the application should not apear in an error message. I don't have a convienient example of one with a password in it (maybe check a more complete source) but this would probabbly also extend to stack traces.
This is a growing list. It gets revised when I see something done well, or something done poorly (or when I do something well, or when I do something poorly. Now I've blogged it.
It started out with just the
Informative rule, motivated by the cost of the support desk having to get involved in a support issue vs. the user working it out for themselves.
More formally, we could look at an error with the following criteria:
- What does this message do for the user experience?
- What does this message do to avoid the user having to call someone?