It's bad enough for users when an application blows sky-high before critical data has been saved. That generates wails of agony that could shatter glass. But what really raises the decibel level is an error message that doesn't explain what went wrong, and, more importantly, how to prevent it happening again.

Sadly, all too many applications (not to mention operating systems) generate error messages that require a secret decoder ring to comprehend (and they're not putting those rings in cereal boxes anymore).

Consider this one: “The application has generated an error and will close.”

How helpful.

The message goes on to ask if it may send a log to its vendor (names are being omitted to protect the guilty—you may cringe in peace). In a recent encounter, a peek into that log by a techie (that is, me) revealed one issue: the PostScript driver for a specific printer was crashing the program (other PostScript drivers did not).

Was it just being coy? Did its developer figure that the user was not sentient enough to understand that a printer driver needed updating? Who knows. But it should not have taken a visit from a techie to tell the user to try a different printer.

To compound the felony, that same “friendly” message also appears in dozens of other situations within that same piece of software. If the application chokes for any reason, it politely announces it is closing and does not admit why.

This is supposed to be user friendly?

Here's another guarantee of user hysteria: “Can't save.” This message was delivered to a helpdesk technician who had just spent ten minutes painstakingly entering vast quantities of information into a trouble ticket.

The application then kindly presented a link to more details. And such details! A whole page of SQL gobbledygook boiled down to the fact that the input was too large for its destination; rather than truncate it, the program was throwing up its hands and doing nothing. Oh—and losing that ten minutes of typing while it was at it.

Ducky. So, next question: how large is too large? To ferret out that tidbit took a call to a developer, who looked at the database schema to find the field size. How hard would it have been to do a little bounds checking on input during development of the app, or to at least generate an error message that meant something to the poor user?

“Runtime error 200” was a goodie that popped up when a user simply tried to start a specific program on his new computer. Everything else ran fine. There was no list of error messages in any of the documentation. The vendor was out of business.

Fun? Wow!

Memory? Tons.

Disk space? Ditto.

It took an extensive Web search to discover that the problem was — are you ready — the computer was too fast! Thanks (?) to a bug in the compiler, it couldn't initialize on a “speedy” 700 MHz machine.

This one obviously is not on the head of the hapless application developer. Instead, the folks who produced—and did not later patch—the offending compiler took the heat in vigorous online discussions. Nonetheless, it was a totally useless message describing a show-stopping error.

Web pages are particularly bad at error handling. For example, recently a user on an airline's Web site, innocently trying to confirm a reservation got, “There was a problem with the request. Please try again.”

Panic ensued. You can imagine what went through her mind as she tried to figure out what was wrong with her apparently correctly typed request.

Actually, nothing was wrong with it. The airline's systems were having a tantrum. So why did they blame the failure on the user?

And so it goes. Pieces of software that otherwise do their jobs very well end up looking bad because of miserable error handling. It alienates the users, it alienates the helpdesk folks who try to assist them, and it alienates maintenance programmers who ultimately have to fix the problems.

Granted, error handling, like documentation, is no-one's favorite thing. It's tempting to cop out and just say, “an error has occurred;” writing something brief and informative that won't incite users to riot is an art. But it's an art that good programmers have to master if their applications are going to survive in that jungle known as the business world.