Well I wouldn’t start panicking; it’s just some program crashing, there’s really no indication at all that it’s malicious. It might be a bit of some messenger program, or some of the rubbish they tend to install to update RealPlayer, or QuickTime, or Acrobat. There’s a million innocent things it could be.
My favourite error:
trying to install 'net-access software, the modem, etc. - it doesn’t work and I get a popup telling me to contact support at http:/ /www.weresocute.com
No phone number, just the linky. Eeeeh… you know… what I’m trying to install is precisely the stuff I need to be able to go anywhere that begins with http (and other interesting and adventurous locations).
Yeah, that’s like the one that’s something like “Keyboard not found. Press Escape to continue.”
Yeah, although in my case it’s definitely Marketing’s fault. I’ll own up to being oversensitive about it right now, too, after receiving it daily for some 3 weeks (every time that the modem said “uh, can’t find a live phone line”). That’s the time it took for my current ISP to figure out that a piece outside my apartment needed replacing.
No other ISPs available in the area. But I’ve gotten those same messages pretty much every time that the computer could not establish the initial connection, apparently all those guys in Marketing went to the same school.
It’s not so much that it’s impractical, it’s that for the vast majority of error conditions it’s completely impossible to know what caused the problem while the software is in development. In fact, a lot of horrible error messages I’ve seen can be partly attributed to an attempt by the programmer to guess at a likely cause (which ends up being wrong) which can result in some hilariously misleading messages. All you can do as a programmer is figure out some sensible way to present the actual failure information in as useful a manner as possible.
Let’s say a program has a component that has to retrieve some information for the user, behind the scenes. This program calls a function called “get the user’s information”. This function in turn calls a function from some library called “open my information file”, and this function in turn calls a system function called “open a file on disk and read the contents”.
Imagine this last step fails, the file is not there for some reason. As a programmer, I have a bit of a problem: I have no idea in the world why or how that file went missing, so I have to try and decide what information to give. The obvious options are:
-
Report the most specific error that can be found: when the system is asked to “open a file on disk and read the contents” and it fails, report that error. This results in messages like the OP’s, where it may be technically accurate (“system could not find file BLAH_12345ABC.FOO” or something), yet completely obtuse.
-
Report the least specific error. That is, when the main program calls the function “get the user’s information”, report that it failed. This is seemingly more useful, because it tells the user what it couldn’t do, but in reality this is the equivalent of a “check engine” light. Since the underlying system error is hidden, and it could be one of hundreds or thousands of errors, it means the user is left unable to do anything himself.
-
Report an error including information from the whole “stack” of function calls. In this case, report that “getting the user’s information failed: getting the information file failed: the file could not be found”. This sounds great, and it’s what a lot of applications are starting to do these days, but in practice it’s very difficult to make work correctly, because in real applications it’s not a simple 3 layer stack like this. What frequently happens is you get 50 lines of technical gibberish, which includes errors from every level of the function leading from most to least specific. My experience is that this isn’t any more readable for non-techie users.
In my own work I’ve been trying diligently to make the third approach work, and in some cases I’ve pulled it off, but it’s very hard to make work for certain kinds of failures. I think this is something that should improve slowly over time, but there’s no easy fix.
Oh, and I should point out that badly implemented error handling (iuncluding unnecessarily obtuse or outright silly messages) does, in fact, infuriate us nerds, too. Check out the Pop-up Potpourri regular feature over at www.thedailywtf.com to see nerds making fun of such things.
Here’s an example I encountered earlier this week. I’m helping a customer with an older program written in the Windows 3.x or 9x days. Meaningful support for this problem from the publisher has dried up. My customer is trying to run this program on new Windows XP computers and gets these two messages:
The application or DLL C:\xyzcorp\wrkspell\xtras\rtkkyf.x32 is not a valid Windows Image. Please check this against your installation diskette.
This program requires at least 3MB of free virtual memory to run.
There’s nothing wrong with the program. It runs fine on other computers on the same network. It’s just that the programmer didn’t foresee his work running on a then non-existent Windows XP machine. He wouldn’t have been able to tell you how to configure Windows XP to use “Compatibility Mode”. He wouldn’t have been able to tell you that you need to lower your initial virtual memory instead of adding more. It is simply impossible for some error messages to convey the necessary steps to resolve the problem.
My favorite easy-to-understand error messages:
“Lint’s little mind is blown” - This was from the original BSD Unix implementation, I had to make it nicer for the DEC release.
And the all time best:
“Data potato - Doo Wop, Doo Wop.” - On the old Dartmouth Avatar editing terminal back around 1983. That was the unrecoverable failure message. It was very soothing when you’d just lost a few hours of work.
Couldn’t agree more. That’s why I wrote:
My favorite error message:
urk
Used for a fatal error. What sound would you make if a knife was plunged into your back?
A good programmer might have approached the problem differently.
Could he have forseen greater memory sizes? Absolutely. He may have checked a memory size and instead of parsing it as three possibilities (greater, lesser, exactly right), ignored one of those. Or failed to recognize that a memory size of zero was probably misleading.
Or the error message he wrote could have said, “Available memory appears to be X as reported by the opsys. You need Y to continue…” which would have been substantually better.
Doesn’t take a genius to handle SOME future errors, but there is as much a skill in this regard as there is in designing perky, animated graphics.
All true. He probably used a data type that wasn’t up to the task of describing today’s vm sizes. Kind of like a Y2K bug. That very well may be pit-worthy. Given that decision, more detailed information in the error message would give “interesting” results since it’d likely be using the same data types.
Sorry, you’re right. I didn’t mean to suggest that no one could fix their own computer, and the procedure you describe is exactly what I do when I get an error message that I don’t understand. With the example in the OP, even though I understand exactly what’s happening (some library was missing), I’d still have to go to Google to see whether I need a replacement .dll or a different version, or if some other programs I had installed were simply incompatible.
But the OP is complaining about an error message that’s more specific than he understands. That’s just silly.