An article about error messages hit a nerve: errors write in with their opinions and frustrations about those darned invalid parameters. Also, a reader questions whether a proper firewall would have spared a ComputerUser columnist some grief.
Having just read your article “A little help, please?”, I couldn’t agree more. That type of error message is useless to the end-user, and with only one option, “OK,” it is even more annoying. What’s the sense in displaying some cryptic message to a user without having a sensible option attached? Perhaps all messages of this type should have a second option–“Reply”–that sends an e-mail to the software designer that says “Your system analyst capabilities suck. Go back to school.” — David A. Odom, Edgewood, Wash., firstname.lastname@example.org
I tried a demo version of Nero Express, but it was not long before I reinstalled Nero Burning ROM. I recall error messages that made no sense, just as you described in your article, “A little help, please?” (I use Windows XP, by the way. And Nero Burning ROM runs on my PC without a hitch.) — Nadetmer Butler, Chicago, ChiPower@ameritech.net
I read ComputerUser on my pocket PC using AvantGo, and I really enjoy the content CU adds to it. You might say my Dell Axim has become my newspaper, bathroom reading material, and late-night browsing all in one. Keep up the good work. I wanted to respond to the comments you made regarding error handling in your article. You paint it as if all errors fall into one big group, and somebody should just spend a little more time improving the lingo. It’s not that simple. Most of the errors that routinely happen during the development of any software are “trapped,” meaning they are well understood, and thus noticed and acted upon by a predefined routine. Every time you see a box stating that you need to insert a disk, or that a device isn’t working properly, you are seeing trapped errors that the programmer handled in a good way.
The types of errors you are referring to in your article are low-level errors that only mean something to the programmer in the context of the programming environment. Those errors are invaluable when coupled with a debugging environment, but they really aren’t intended for end-users. Things like “parameter invalid” can happen hundreds of places in the code, and the reason why it is invalid is meaningless unless you are staring at the code.
Perhaps the programmer forgot to initialize a variable, or passed an empty array to a function that doesn’t allow an empty array. There is no way for software to enunciate why a programmer broke a rule, because the logic was in the programmer’s head, not in the code. All the software environment can do is tell you what didn’t work. My point is, it simply isn’t possible for all those messages to be made more understandable for the consumer, because the underlying problem that created it is meaningless to the consumer. If, as you pointed out, that the same error message shows up for a multitude of different reasons in a vendor’s code, then their coding practices are likely poor and their evaluation and debugging practices are weak. I would look to another vendor. — Tim Jones, Rockford, Ill., email@example.com
I read the article titled “The limits of disaster” by Nelson King. Nowhere in his article did he mention whether he had a firewall installed. Did he? If he had Zone Alarm or something similar and he followed long-published recommendations to refrain from opening up attachments, he would not have been hit by Blaster. The worm was not only coming in through opening attachments, it was also coming in directly through open network ports 135, 139, 445 and 593 (TCP and UDP). — JW, firstname.lastname@example.org
to start a discussion or ask a question, e-mail email@example.com. letters may be edited for style, length, or content. no anonymous letters will be published.