FREE Subscription to Dr. Dobb’s Digest: Same Great Content, New Digital Edition
Site Archive (Complete)
Testing & Debugging Blog: Who Writes These Error Messages?
Testing and Debugging
BREAKPOINTS

Test, Debug, Release, Rinse, Repeat ...

by Kevin Carlson
THE BOOK OF TESTING

Thoughts From a Braidy Tester

by Michael Hunter
September 11, 2006

Who Writes These Error Messages?

I'm not sure how sensible it is for me to point out our own flaws here on the Dr. Dobb's Portal, but I'm afraid I can't pass this one up. If you hadn't noticed, we had a little server problem today. I hope this didn't inconvenience you too much. It certainly inconvenienced us.

While the IT team was slaving feverishly under the whips of their masters to restore server availability, I had plenty of time to contemplate the 403 error our server throws when the evil spirits take it:

"You have requested data that the server has decided not to provide to you. Your request was understood and denied."

That's reassuring. I'm really glad my request was understood, because my real concern here was that the server wouldn't understand that I was making an http request, and would instead think I was ordering a cheese pizza.

Now, before you accuse me of being intentionally obtuse, I do understand that this error meant something to someone when it was written. They always do. Perhaps the author of this particular server had spent a good amount of time in debugging sessions wondering "Is the request handler broken, or is it something in the security setup?" So maybe this error message specifically disambiguates between the two, and maybe that was a big help to the developer.

But once your code is out there in the wild, talking to people other than you, shouldn't you really make sure your error messages aren't coy, or worse, downright mean-spirited and capricious? Or at least you should go for the *nix "printer on fire" sort of error-message humor. And yes, I know that some people claim that the "printer on fire" message originally (we're talking decades ago, here) was intended to indicate a condition that represented a significant risk that the printer might actually BE on fire. This might be urban geek legend, or it might not. Either way, it pays to reevaluate the relevance of your error messages before your software gets anywhere near a user in its natural habitat.

Posted by Kevin Carlson at 04:46 PM  Permalink




 
INFO-LINK