The art of helpful error messages

While looking at off-the-shelf software with not so polished user interfaces, you can see some error messages that are just plain stupid. Some might state that an error just occured, others say that the program cannot continue. Error messages can sometimes make the user feel powerless and lost.

Ideally, error messages should help focus the user towards how to go on with the currently stopped procedure.

It is really hard for the coders to describe the error help well for the users, simply because the context when coders write code is not the same context as when users use the product. I claim that really well described error messages are the result of many polishing iterations of using the product and modifying the code. That requires a lot of hard work.

I further think that the quality begins in the code with a sound level of throwing and catching exceptions. Your low level code should throw as many detailed exceptions as you can. Your middle level code should interpret and throw their own exceptions classes since they offer a different context to their users than the low level context. Your application code can add another layer of exception classes as well as be the end-point of error handling, like displaying the error and tips, log the error, shutdown, order a restart, or anything else.

Well-written error messages has a low priority and is a pretty much ignored area during software development, along with documentation. Not so if users could decide.