Is this actually possible? How do you code for “what I thought was an unreachable state”?
I gather it could be a case of exception handling:
The gist of this snippet is that x has an integer value where only certain ranges are acceptable. If x is unacceptably negative [i.e. *if (x < 0)*], the program will “throw an exception” and run special code (in the “catch” portion) to handle the unusual case, ideally before passing a negative x to another routine which will then crash, i.e. before passing x to a routine that will calculate the square root of x.
I gather the programmer in the cartoon imagined some weird, wildly improbable value for x (or whatever the variable in question is) and wrote a message saying in effect “I wrote this message just in case this wildly improbable circumstance occurred, but I’m too tired right now to think up a good way to handle the situation.”
I think it’s more like he’s written code such that some condition ought never happen - like
If x>0 then
Do this;
Else if x<=0
Do that;
Else;
Panic!
End
If coded correctly there’s no way to get to the “Panic!” (x is either greater than zero or less than or equal to zero) - but an error in the code (like a way that x could change between the first two “ifs”) might make it possible to get to that point - and the poor programmer, recognizing if the system gets to “Panic,” it means that he made a subtle error that he’s incapable of figuring out, is writing a response that acknowledges that he’s the wrong person to be providing advice about what to do.
Yes… but exception handling is a more formal approach than writing a bunch of if/then/else lines.
Absolutely - I was using the if/then/else just to provide a simple informal example.
Typically used in the “default” option of switches:
switch (value)
{
case 1:
DoThings()
break;
case 2:
DoOtherThings()
break;
default:
//Shouldn’t happen.
break;
}
Writing your own code and getting it mostly right is really hard. When other people are involved, and esp. as the software evolves over time, stuff starts getting Byzantine. So you’re responsible for a library that’s intended to be used in one context. Needs change so someone has the bright idea to use it another context. Being a little prescient you put in such an error message in your original code to handle stuff that shouldn’t happen. E.g., the hard drive your code is managing isn’t there anymore. When you wrote the code, USB drives didn’t exist.
Since you can’t program in all the weird things that might happen someday in the future when other stuff changes, you put in a default “Something really bad happened.” error message.
In short: It is impossible to predict what may wrong in the way the code is used in the future.
(Just checked. The XKCD forums were taken offline due to a hack on the 2nd. And they’re still down. There were so little used I now think that it might be permanent.)
I have often been in scripting situations where it seemed to me that things were as basic as this:
… but where, yes indeedy, there was something I had not taken into account.
TL;DR’ish example for anyone who wishes an example:
I had a field on the database layout that was defined in such a way that it would never be empty – not only did it have an autofill startoff value, but validation requirements explicitly stated that field should not be empty and should be unique.
Under rarified circumstances – importing from a different system that might have overlapping values from the source, until they were properly modified by my import routine script – this field might contain numerical values that were not whole numbers (integers) but instead had a decimal point and an imposed tenth so as to shift them to a guaranteed-unique position. (My script would then fetch the lowest not-yet-in-use integer and apply it to the imported record and its child recs, thus getting rid of the temporary decimal).
Well, a numerical value either IS a freaking integer or it has a modulo (“remainder”) if divided by 1, right?
The thing I hadn’t counted on: FileMaker has a mode called “Find Mode” in which one is not situated on data, but instead is situated on a REQUEST which starts off with all fields empty (and the user populates the fields to specify what they wish to find).
The other thing I hadn’t counted on: A previous part of the import routine did not have the user’s ability to abort or pause operations to be disabled, and one of them hit the freaking escape key, god knows why, and then, with everything paused, chose to enter Find Mode.
The bloody field is blank in Find Mode (unless the user types in a number or numerical range expression). A blank field is neither an integer nor does it have a modulo.
“Hey AHunter3, I got a message onscreen that says ‘Nobody’s ever supposed to see this’, what did I do?”
/ TL;DR
Thanks.
“Never test for an error condition you don’t know how to handle.” --Apocryphal law of computer programming attributed to various authors.
There is a story I heard when working for Radio Shack. The version I’ve heard was supposed to have occurred at Radio Shack. (I have seen a similar version, only set in an Oil & Gas Co, but the page below makes me think the Radio Shack version is more likely)
A developer was working on the software for a Xenix system (Tandy’s flavor of unix) and ran into a potential hardware problem that should never happen. So he put the test in for it, and made the error “Shut her down, Scotty, she’s sucking mud”
In the story I heard, it did happen, and in the office of one of the upper muckety-mucks. Fortunately, the programmer had gone on to greener pa$ture$ by that time.
This page doesn’t have the follow-up, but credits the programmer who put the error message in.
Floating-point variables can have the value NaN, which has some odd properties. Most famous is that a NaN is not equal to itself (that is, nan==nan is false). It would also fail both comparisons in this code snippet and hit the panic mode.
Another good example.
The point of the comic’s joke is that the coder in the comic is tired and depressed enough that as he’s writing the display for supposedly impossible conditions, he has to acknowledge that the person makes the mistake allowing the impossible condition to occur is not the best person to advise what to do in those circumstances.
I suppose the error message “Hodie Natus Est Radici Frater” is apropos here.
I’ve definitely written an error message of that sort before. In my case it’s usually because I’m coding something to a technical spec that is at least a little bit ambiguous (as they all are), and I have to make some assumptions about how to resolve that ambiguity in code.
At some point I’ll likely have a few “I don’t know how this happened, but some invariant I thought was true really wasn’t” sorts of states. At some point, you just want a unique error so that when someone says “Hey, I saw an error that said this dumb thing”, you can search for that dumb thing in the code and see where it got to.
Small world, I worked with Frank when we were both at a dialup ISP in the 90s (Internet America, the 1-800-BE-A-GEEK people for anyone who was in the Dallas area at the time).
I recall him telling stories of his time at Tandy, but I don’t recall anything about this specific one.
Related:
-handwritten note in one of John von Neumann’s lab books. I hear ya, brother!
Oracle PL/SQL has exception handling. There are many built in exceptions, and you can define new ones. One of the built-ins is “WHEN OTHERS…” caught when everything else has slipped through.
You could put:
WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE('Oh dear something unexpected happend')
(and append an actual error code)
The most common solution is:
WHEN OTHERS THEN NULL
…nothing to see here folks. No clues. You’re you’re own your own here.
P.S. From Code Complete (paraphrased). (Even if you never expect them to occur) do not use “cute” error messages.
Way back in pre-historic times, I coded in Lisp which had a function for just this type of situation. IIRC, the function was called “shouldnt”.
J.
Am I correct in my recollection that this type of situation is the origin of the legend of the legendary “Halt and catch fire” instruction?