A programmer's pet peeve
Last Friday, I was trying to install a particular product on a machine running Windows Vista, and ran into problems. Installation of products on Vista sometimes causes unexpected errors due to the new security model, but this one, as it turned out, would have existed had I tried to install it on a Windows XP machine. Apparently, I had to ensure that jscript.dll was registered on the local machine, something I did, which made the problem go away. What turned my face red, however, was the error message that initially popped up, which read:
Internal Error 2739.
Those kind of messages drive me crazy. My opinion as a working developer is that any programmer who pops a human-readable message with a numeric error code needs to spend a month in a building where everyone speaks by spelling out words using the numeric Unicode value of each letter. What (I would say to the protesting developer), you find that mode of communication confusing? Then why the hell are you popping a window that shows you nothing more than a numeric error code? Are we supposed to understand what that means?
For those who commit an even worse sin - popping a message that provides even less information, such as...
An Error Occurred
...which is the verbatim text of a message that I received from a certain unnamed software product a few weeks ago, the penalty is more severe. They get to spend a year in a land where deranged language simplification engineers have reduced the tens of thousands of words in the English language to one word - Microsoft. Try figuring out where the bathroom is when all you hear in response is the name of the largest software company in the world repeated over and over again.
Here's what I do when I get an unexpected error in a .NET application (which is relevant cross-platform, as I think most modern UI code should be written atop a managed runtime environment like .NET or Java). I create a message box that has a non-technical explanation of what went wrong, which for truly unexpected errors (versus something I can categorize by a base exception class) is nothing more than an "An unexpected error has occurred" message. I then create a Details button which expands to show a) the type of exception I received (.NET, like Java, is a self-describing environment), b) the full message text of that exception, and c) the full stack trace of that exception. This is all information contained in the standard Exception objects used in both Java and .NET.
No, I don't expect non-technical users to know what to do with this detail. If, however, I am to help them debug the problem, that information is indispensible to me. Further, if the user is mildly technical, it might even help them. A recent customer was able to use that information in an application I wrote to determine that he didn't have security rights to a share he was trying to access. Granted, in an ideal world, I would trap that kind of error and provide a proper message tailored to the particular problem. There are, however, corner cases, and developers have time constraints.
If I provide verbose information for unexpected errors, end users at least have a chance to figure out what is going on. When developers pop (at best) little more than an error number, or worse, an error number that is not documented anywhere and IS ONLY USEFUL TO THE INTERNAL DEVELOPMENT TEAM (as was the case with an error code I received not too long ago from a Linksys WiFi Print Server product), that is worse than annoying...it is downright consumer unfriendly.
Fortunately, as we move ever deeper into managed runtime territory, it becomes easier to provide useful information even when a developer missed a possible error that would merit a tailored message string. To quote an old Wendy's commercial, "show us the beef" if the program doesn't know what happened. Don't tell us something went wrong without providing us, to the best of your ability, with as much information as possible as to what that something was.