Really, aside from invalid input (in all of its many and varied forms) or broken hardware (in all of its many and varied forms), almost all computer error messages crop up because something happened that the programmer thought couldn’t happen. If the programmer was very, very clever, then even when that “impossible” thing happens, the program will continue running as it “should”*. But sometimes, no programmer is clever enough.
*One of my proudest moments as a programmer was when the virtual Rubik’s Cube I had made had a “sticker fall off”, and it continued blithely along in exactly the same way as a real Rubik’s Cube with a missing sticker. Some cosmic ray or other unreproduceable glitch set the byte storing the color of that spot to 0, which was (of course) the color code for black, and so the other routines moved that black spot around the surface of the cube in just the same way they would have done for the orange spot it was supposed to be.
Long ago I was working on a large team on a very large software project. There was a software condition that I thought couldn’t happen, but if it did happen to another developer I wanted to run over to their desk and investigate it immediately while the system was still in that state. So I put in an error message that said “If you see this message call markn+ immediately at extension 1234.” Well the condition never happened and I more or less forgot about the message. The system was released with this message still in the software. Sure enough, some customers starting seeing the message, and some of them dutifully called the company and asked to speak to markn+ at extension 1234. (There was nothing I could do to investigate the problem on a customer’s system.) That was a valuable lesson to me about being careful how you word an error message, and about leaving debugging code in a production system.
A software product I use at work has an error message like this. It refers the user to the guy who maintained the code years ago, who isn’t here any more.
I would posit that some of you are overthinking a very simple concept. “Should never get here” is quite a common comment to see in code. I’d say there are two different situations that this can be taken to represent. One, as some have already noted, is the trivial case of a code branch that can only be reached if all logical possibilities are exhausted, which means some type of bizarre hardware condition or glitch has occurred. The other is a state in a complex algorithm that the programmer never anticipated, but which is in fact logically possible.
Perhaps not directly relevant, but I once had an excellent book on software reliability that had a chapter talking about a missile defense system that was being built for the DoD to detect incoming enemy missiles. The designers obviously went to great lengths to eliminate false positives from birds, airplanes, and any other airborne objects they could think of. The title of the chapter: “Why the moon is not an incoming enemy missile”.
Let me also take this opportunity to say to all programmers that anyone who thinks “An unexpected error has occurred” is a useful error message should be fired immediately, pissed on, and never allowed to work in the software industry again. Besides being completely and utterly useless, it’s also semantically annoying. What’s the alternative to an “unexpected error”? Perhaps a message like, “An error has occurred, but I was fully expecting it”? These useless messages are not only common in a lot of PC software, including mainstream Microsoft applications, but they can occur under quite common conditions, such as not having some optional software component installed. So even the feeble excuse that the error was thought to be so unlikely that it didn’t warrant any diagnostic information at all doesn’t fly.