Unexpected error

If you aren’t a computer programmer, no doubt you’ve been really frustrated by an unhelpful error message. Actually, programmers get frustrated by it too.

The thing is, when you’re developing software you often run into places where an error could happen, but you have no idea what could cause such an error. You might know a low-level, programmer-speak reason for the error, but you aren’t aware of the bigger picture that would allow you to write an error message that would be useful to end-users.

This lack of context isn’t for a lack of trying to understand. It is because our computers are very complex system with lots of hardware and software created by many different people and many different organizations. It’s just too complex to know all the different behaviors that can emerge. Not to mention that you will expect my software to work with hardware and other software that I don’t even know exists.

Even when you have the context to write a good end-user error message, there’s a good chance that the same error will happen in a completely different context that you couldn’t have anticipated, which will make your helpful error message misleading instead.

So, often, the best you can do is write a message that will help you know what went wrong. Then when the customer calls, you can figure it out. Then you can fix the problem for that customer and make sure you have a more helpful message in the next release.

There’s still a good chance, however, that a completely different circumstance will then trigger the same error and this helpful message will end up being misleading for those users.

Since error messages that are useful for debugging end up frustrating end-users more than generic error messages, they tend to get discouraged. So we end up with the worst of all worlds: Error messages that are completely useless to everybody.