#1  
Old 09-11-2019, 07:41 AM
Lumpy's Avatar
Lumpy is offline
Charter Member
 
Join Date: Aug 1999
Location: Minneapolis, Minnesota US
Posts: 16,668

Xkcd 09-09-19


https://xkcd.com/2200/

Is this actually possible? How do you code for "what I thought was an unreachable state"?
  #2  
Old 09-11-2019, 08:16 AM
Bryan Ekers's Avatar
Bryan Ekers is offline
Charter Member
 
Join Date: Nov 2000
Location: Montreal, QC
Posts: 59,258
I gather it could be a case of exception handling:
Quote:
#include <iostream>
using namespace std;

int main()
{
int x = -1;

// Some code
cout << "Before try \n";
try {
cout << "Inside try \n";
if (x < 0)
{
throw x;
cout << "After throw (Never executed) \n";
}
}
catch (int x ) {
cout << "Exception Caught \n";
}

cout << "After catch (Will be executed) \n";
return 0;
}
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."
__________________
Don't worry about the end of Inception. We have top men working on it right now. Top. Men.

Last edited by Bryan Ekers; 09-11-2019 at 08:19 AM.
  #3  
Old 09-11-2019, 08:26 AM
Andy L is online now
Member
 
Join Date: Oct 2000
Posts: 6,691
Quote:
Originally Posted by Bryan Ekers View Post
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.
  #4  
Old 09-11-2019, 08:32 AM
Bryan Ekers's Avatar
Bryan Ekers is offline
Charter Member
 
Join Date: Nov 2000
Location: Montreal, QC
Posts: 59,258
Yes.... but exception handling is a more formal approach than writing a bunch of if/then/else lines.
__________________
Don't worry about the end of Inception. We have top men working on it right now. Top. Men.
  #5  
Old 09-11-2019, 08:39 AM
Andy L is online now
Member
 
Join Date: Oct 2000
Posts: 6,691
Quote:
Originally Posted by Bryan Ekers View Post
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.
  #6  
Old 09-11-2019, 11:12 AM
Frodo's Avatar
Frodo is offline
Guest
 
Join Date: Sep 2001
Location: Buenos Aires, Argentina
Posts: 2,288
Typically used in the "default" option of switches:

switch (value)
{
case 1:
DoThings()
break;
case 2:
DoOtherThings()
break;
default:
//Shouldn't happen.
break;
}
  #7  
Old 09-11-2019, 01:03 PM
ftg's Avatar
ftg is offline
Member
 
Join Date: Feb 2001
Location: Not the PNW :-(
Posts: 20,342
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.)

Last edited by ftg; 09-11-2019 at 01:04 PM.
  #8  
Old 09-11-2019, 01:18 PM
AHunter3's Avatar
AHunter3 is offline
Charter Member
 
Join Date: Mar 1999
Location: NY (Manhattan) NY USA
Posts: 20,606
I have often been in scripting situations where it seemed to me that things were as basic as this:

Quote:
Originally Posted by Andy L View Post
If x>0 then
Do this;
Else if x<=0
Do that;
Else;
Panic!
End
... 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

Last edited by AHunter3; 09-11-2019 at 01:19 PM.
  #9  
Old 09-11-2019, 01:31 PM
Andy L is online now
Member
 
Join Date: Oct 2000
Posts: 6,691
Quote:
Originally Posted by AHunter3 View Post
"Hey AHunter3, I got a message onscreen that says 'Nobody's ever supposed to see this', what did I do?"

/ TL;DR
Thanks.
  #10  
Old 09-11-2019, 03:16 PM
Ponderoid is offline
Guest
 
Join Date: Jan 2008
Location: Off the Deep End
Posts: 701
"Never test for an error condition you don't know how to handle." --Apocryphal law of computer programming attributed to various authors.
__________________
That's my post. Hope you liked it!
  #11  
Old 09-11-2019, 03:48 PM
Zyada is offline
Guest
 
Join Date: Apr 1999
Location: Foat Wuth!
Posts: 5,313
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.
  #12  
Old 09-11-2019, 04:47 PM
Pleonast's Avatar
Pleonast is offline
Charter Member
 
Join Date: Aug 1999
Location: Los 'Kamala'ngeles
Posts: 7,289
Quote:
Originally Posted by Andy L View Post
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.
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.
  #13  
Old 09-11-2019, 04:50 PM
Andy L is online now
Member
 
Join Date: Oct 2000
Posts: 6,691
Quote:
Originally Posted by Pleonast View Post
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.
  #14  
Old 09-11-2019, 05:40 PM
beowulff's Avatar
beowulff is offline
Member
 
Join Date: May 2001
Location: Scottsdale, more-or-less
Posts: 16,822
I suppose the error message "Hodie Natus Est Radici Frater" is apropos here.
  #15  
Old 09-11-2019, 06:31 PM
iamthewalrus(:3= is offline
Guest
 
Join Date: Jul 2000
Location: Santa Barbara, CA
Posts: 12,042
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.
  #16  
Old 09-11-2019, 07:06 PM
dzeiger is offline
Guest
 
Join Date: Jan 2009
Location: Frisco, Tx
Posts: 1,696
Quote:
Originally Posted by Zyada View Post


This page doesn't have the follow-up, but credits the programmer who put the error message in.
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.
  #17  
Old 09-11-2019, 08:20 PM
Bryan Ekers's Avatar
Bryan Ekers is offline
Charter Member
 
Join Date: Nov 2000
Location: Montreal, QC
Posts: 59,258
Related:

Quote:
"5 a.m.: I've been at this all night, and I still can't find the problem. I'm disgusted and I'm going to bed!"
-handwritten note in one of John von Neumann's lab books. I hear ya, brother!
__________________
Don't worry about the end of Inception. We have top men working on it right now. Top. Men.
  #18  
Old 09-12-2019, 12:49 PM
Small Clanger is offline
Guest
 
Join Date: Oct 2003
Location: Milton Keynes
Posts: 2,598
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:
Code:
WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE('Oh dear something unexpected happend')
(and append an actual error code)
The most common solution is:
Code:
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.
  #19  
Old 09-13-2019, 03:43 PM
jharvey963 is offline
Member
 
Join Date: Oct 2004
Posts: 1,693
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.
  #20  
Old 09-13-2019, 03:44 PM
KneadToKnow is offline
Voodoo Adult (Slight Return)
Charter Member
 
Join Date: Jul 2000
Location: Charlotte, NC, USA
Posts: 26,586
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?

Last edited by KneadToKnow; 09-13-2019 at 03:44 PM.
  #21  
Old 09-14-2019, 09:59 AM
Chronos's Avatar
Chronos is online now
Charter Member
Moderator
 
Join Date: Jan 2000
Location: The Land of Cleves
Posts: 85,174
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.
  #22  
Old 09-14-2019, 11:36 AM
markn+ is offline
Guest
 
Join Date: Feb 2015
Location: unknown; Speed: exactly 0
Posts: 2,679
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.
  #23  
Old 09-14-2019, 12:02 PM
puzzlegal's Avatar
puzzlegal is offline
Member
 
Join Date: Jul 2014
Posts: 4,841
Quote:
Originally Posted by markn+ View Post
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.
  #24  
Old 09-14-2019, 05:53 PM
wolfpup's Avatar
wolfpup is offline
Guest
 
Join Date: Jan 2014
Posts: 11,109
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.

Here's ExplainXKCD's take on that cartoon.
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 07:35 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.

Send questions for Cecil Adams to: cecil@straightdope.com

Send comments about this website to: webmaster@straightdope.com

Terms of Use / Privacy Policy

Advertise on the Straight Dope!
(Your direct line to thousands of the smartest, hippest people on the planet, plus a few total dipsticks.)

Copyright 2019 STM Reader, LLC.

 
Copyright © 2017