Attention programmers… This is NOT how you make a useful error message that helps the user address the problem or at least gives them something useful to work with on Google:
My all time fave is the old Apple message “An error has occurred because an error has occurred”.
I am upset this site has closed !
https://web.archive.org/web/20181020091024/http://errorwear.com/
I like the Guru Meditation numbers on the Commodore Amiga.
how bout the old Windows “Illegal Operation” messages, scaring old people half to death that the feds would come knocking! Had a tough time getting grandma to try using her PC again after one of these
I love this whole thread! Some of these, like the “Something Happened,” it’s hard to believe they’re real! LOL!
One of the old Winamp devs put a guru meditation in as the error window if a plugin crashed. possibly the modern skin plugin.
Opera blogs used to show a guru meditation error and an ASCII Buddha if the page was down.
Here is a message from my win10 PC.
I remember that very well!!!
The best fictional error is from StrongBad’s emails:
Since the original version requires flash, here is the next best thing:
I remember the IMFart error from the AOL software.
As a programmer I would on occasion write code in which a decision could lead down one of several paths. Some of these paths were logically impossible as earlier decisions prevented the execution from ever reaching them. Nevertheless I still inserted error messages along the lines “Impossible error – cannot reach this point.” Frankly, this was so long ago I don’t recall if they ever popped up.
On a related topic, my favorite line of code was a call to an operating system function to abort the program. If the call worked the program stopped running and if the call failed the program stopped running.
I did that, too, and occasionally they might get triggered - usually by a serious data error resulting in a stored value that was logically impossible for the field that held it (no data typing). For example, the systems I worked on encoded negative numbers as very large positive numbers, so if a calculation went completely bananas and produced an impossibly large result, it would be interpreted by the OS as a negative number, potentially invalidating any test on the value of the field holding it.
The biggest danger in programming this sort of code was the assumption that you knew the format or values of the data you were processing, so in any chain of tests we always had a “bucket at the bottom” error message to catch any “impossible” states. Because occasionally the impossible could happen.
Certainly possible. In my case I was using a language, Fortran 66, which by today’s standards probably had weak data typing.
I was working in Assembler, with lengthy forays into machine code for patches between release dates. The ability to write in binary to any area of memory by address rather than data name effectively bypassed any concept of typing. Required care when coding, but made debugging easier.
We’re showing our age!
Well played sir, well played. Bonus points for the xkcd comic. It was so easy to write bad code under those conditions I’m amazed that anything worked.
These days I get “Catastrophic failure” Messages in Visual Studio…
In my former employer I was frequently requested to do code reviews because it is something that I did well. I tended to use them as a teaching opportunity when finding something I didn’t like. One of the things I always tried to teach people was to make the error message (or exception message in Java terms) give the developer information they would wish they had if they were the one assigned to investigate an error that they couldn’t reproduce. It takes more effort to do it, but it’s much handier than “error occurred.”
Which would you rather investigate as a developer:
a) error occurred
b) unexpected value for size
c) unexpected value for size(42)
d) unexpected value for size(42) in buildSpace(mode=upscale,model=treehouse)
I have also become a huge fan of a small FIFO of recent trace data, aka a “flight recorder” that can be dumped when things go wrong. It doesn’t need to do too much, but if it can show recently invoked functions of the code it can give someone a hope of finding and fixing a bug.
Unfortunately designing for failure takes even more effort to do and most programmers wrongly (and lazily) believe their code will never break.
I was just reminded of the Task Failed Successfully Error from windows XP.