I just tried having a look at my guild’s old message board to make sure nobody’s missing the big “Come visit us at our new location!” banner and posting messages that will never be seen, and instead of the message board, I’m greeted by an animated GIF of a character banging his head on the desk and the text Sorry, but this service has suffered an unrecoverable error of some sort.
My favorite error message is from AIPS, software for analyzing data from radio telescopes. When it puked, it said, “PURPORTS TO DIE OF UNNATURAL CAUSES.”
That’s pretty much AIPS in a nutshell, right there.
There were a few other funny things . . . a routine for purging your history called STALIN which, upon successful completion, reports “2938 RECORDS HAVE BEEN SENT TO SIBERIA.” The manual, called The AIPS Cookbook, also contained several banana recipies.
I remember when I was new to computers and saw my first Fatal Error. I had a shit attack, I thought it was really dead. It’s stupid, but I was a total n00b :eek:
I worked with a bad Pascal compiler back in the early '80s. No matter what caused the compilation error, the only error message I ever got from that compiler was: “Semicolon expected”. :wally
Then there’s the plethora of Unix shell commands, whether they succeed or fail, all they do is exit leaving you with the system prompt begging for your next command to be entered.
When I was using ArcGIS software this summer, I at one point wanted to extend some line I’d made to a specific length. I was looking for how to do that and tried “Trim to Length,” where I entered the new, greater length. I got an error saying “Trim length cannot exceed total lenght, dude.”
It only took that “dude” to get a kick out of me that day.
I worked on some oddball computers years ago that ran proprietary operating systems. This one particular operating system was almost as terse as Unix with it’s error detection. If you entered a command incorrectly, it would say:
“Command Error”.
The users complained that the operating system was not user-friendly, it didn’t tell you WHAT the error was. In the next version of the operating system, if you entered a command incorrectly, it would say:
“Your Command Failed, Please Re-enter Your Command - Thank You”.
I don’t know, it seems to me a lot of programmers are sloppy and lazy, they never check for errors. I always tried to checked for error conditions and displayed an error message containing the name of the operation that failed, and maybe a file name or port number or whatever was involved, along with the status registers indicating the precise error. I was big on log files too, so you know when the program was started and you have a hard-copy history of the errors.
It’s really strange, I get job offers to support crappy code, code that doesn’t give you a clue why it failed. If I take the job I usually eventually modify the code to display error messages and have a log file. Invariably the person who originally wrote the code gets irate because their expertise is no longer needed to track down the errors in their crappy code. And most managers I have worked for would rather hire 5 more support people than fix the problem. Dang, I’m always such a trouble maker. :rolleyes:
My supervisor is in charge of the HP-UX boxen. He was putzing around with the Raid6 beta, and shortly, I received the following message:
I found this while doing a make menuconfig…
This is the help text for the RAID6 option… lol
x WARNING: RAID-6 is currently highly experimental. If you
x use it, there is no guarantee whatsoever that it won’t
x destroy your data, eat your disk drives, insult your mother,
x or re-appoint George W. Bush.
I wrote a device driver for an async interface that used a chip that contained a silo. Got all that?
For those not interested in the gory details of this interface, GOTO PUNCHLINE.
A silo is just a hardware buffer for incoming characters, if your driver can’t keep up, the characters go into the silo rather than having data over-run errors. So my driver would service an input interrupt, then loop through the silo until all the characters were read, then wait for the next interrupt. Well, like most hardware gizmos, this one had its quirks. See, you could set the high water mark on the silo for an interrupt, that is, don’t wake me up until there’s at least X number of characters in the silo. Due to various real time constraints I had to mess with this feature.
You still with me?
So, I would mess with various silo trigger points and observe the behavior of the system. Well, as you can imagine, sometimes there were a couple characters waiting in the silo for a long time, so I implemented a timer to go empty the silo periodically. This type of operation screwed up the hardware’s logic with silo processing, so instead I FORCED the chip to interrupt me by toggling the interrupt bit in the status register. This bit was supposedly read-only, but I found if you toggle it, it would cause the chip to issue a hardware interrupt. So I thought, hmmm, let’s see how this works.
PUNCHLINE:
When I forced the chip to interrupt, the message I found in the input buffer said:
I love the errors I occasionaly get from a certain type of mail server. I am not sure which software platform it runs on, but if you send a mail through it which cannot be delivered it writes back with: (paraphrasing)
“Hello, this is the XYZ mail server. I was unable to send your mail to soandso@email.com. I am sorry it didn’t work out.”
Such a polite email server!!