This should never happen.



  • The one good thing about code with no reasonable documentation is that you can get programmers arguing with each other within comments.  Found this today and had to burst into laughter:

    /* this should never happen !  ha, seen that before */

    I wish I knew who added that second part.  I've seen too many other occurances of "this should never happen", and would like to befriend whoever else shares my sympathies.  My guess is that, unlike the originator of "this should never happen", my sarcastic friend no longer works here.



  • @vt_mruhlin said:

    The one good thing about code with no reasonable documentation is that you can get programmers arguing with each other within comments.  Found this today and had to burst into laughter:

    /* this should never happen !  ha, seen that before */

    I wish I knew who added that second part.  I've seen too many other occurances of "this should never happen", and would like to befriend whoever else shares my sympathies.  My guess is that, unlike the originator of "this should never happen", my sarcastic friend no longer works here.

     

    Reminds me of an ATI graphics card I had on my previous system.  Whenever I updated the driver and selected "Yes" to restarting, windows would begin shutting down applications so it could restart.  One of those "not responding" popups would always come up and disappear within a few seconds that said in the title bar "End Program - Should not see me."
     



  • This is what asserts are for.  When the impossible thing happens, you'll be alerted instead of having to dig through until you notice the comment.





  • @seaturnip said:

    This is what asserts are for.  When the impossible thing happens, you'll be alerted instead of having to dig through until you notice the comment.

    Error logs or properly handled exceptions are less...destructive...ways to handle it.  Reminded me of the argument I had with an old boss where our code was "crashing" in production when an assertion failed in a certain open source library.  "All the have to do is build it with -DNDEBUG and handle the exception ourselves.  We should have been doing that from the start"  He disagreed because he thought the assertion failing meant our code was sending input that was causing a coredump.  I had to show him the actual code from the library and explain to him in very simple terms what an assertion is. Code was something like:

    assert(connection.isActive());
    if(!connection.isActive())
         throw Exception("connection is inactive!");

    Since that monumental undertaking I've pretty much decided that assertions should always be avoided.  Might make testing a little bit harder, but makes dealing with your PHB a little easier.



  • @seaturnip said:

    This is what asserts are for.  When the impossible thing happens, you'll be alerted instead of having to dig through until you notice the comment.

    And in most cases, #define NDEBUG is intended to be used for production code. 



  • @vt_mruhlin said:

    @seaturnip said:

    This is what asserts are for.  When the impossible thing happens, you'll be alerted instead of having to dig through until you notice the comment.

    Error logs or properly handled exceptions are less...destructive...ways to handle it.  Reminded me of the argument I had with an old boss where our code was "crashing" in production when an assertion failed in a certain open source library.  "All the have to do is build it with -DNDEBUG and handle the exception ourselves.  We should have been doing that from the start"  He disagreed because he thought the assertion failing meant our code was sending input that was causing a coredump.  I had to show him the actual code from the library and explain to him in very simple terms what an assertion is. Code was something like:

    assert(connection.isActive());
    if(!connection.isActive())
         throw Exception("connection is inactive!");

    Since that monumental undertaking I've pretty much decided that assertions should always be avoided.  Might make testing a little bit harder, but makes dealing with your PHB a little easier.

    Uh, okay, but those of us who work in sane, well-managed companies can and should keep using them.



  • @vt_mruhlin said:

    The one good thing about code with no reasonable documentation is that you can get programmers arguing with each other within comments.  Found this today and had to burst into laughter:

    /* this should never happen !  ha, seen that before */

    I wish I knew who added that second part.  I've seen too many other occurances of "this should never happen", and would like to befriend whoever else shares my sympathies.  My guess is that, unlike the originator of "this should never happen", my sarcastic friend no longer works here.

    How about this code?

    throw new Exception();
    doBar();
    

    Not only should doBar() never happen, but it should never have been written!  I come across these constructs daily in the codebase I'm working on.
     



  • @vt_mruhlin said:

    The one good thing about code with no reasonable documentation is that you can get programmers arguing with each other within comments.  Found this today and had to burst into laughter:

    /* this should never happen !  ha, seen that before */

    I wish I knew who added that second part.  I've seen too many other occurances of "this should never happen", and would like to befriend whoever else shares my sympathies.  My guess is that, unlike the originator of "this should never happen", my sarcastic friend no longer works here.

    Surely

    /* this should never happen */

    code to handle it if it does

    is better than not even having realised that it MIGHT happen, doing nothing about it, and having the program go kablooey.



  • @seaturnip said:

    Uh, okay, but those of us who work in sane, well-managed companies can and should keep using them.

    What, both of you?



  • http://google.com/codesearch?hl=en&lr=&q=%22shit%22&btnG=Search

     There's one part of the way down that reads:

     

    	/* Sun, you just can't beat me, you just can't.  Stop trying,
    * give up. I'm serious, I am going to kick the living shit
    * out of you, game over, lights out.
    */


     



  • @vt_mruhlin said:

    @seaturnip said:

    This is what asserts are for.  When the impossible thing happens, you'll be alerted instead of having to dig through until you notice the comment.

    Error logs or properly handled exceptions are less...destructive...ways to handle it.  Reminded me of the argument I had with an old boss where our code was "crashing" in production when an assertion failed in a certain open source library.  "All the have to do is build it with -DNDEBUG and handle the exception ourselves.  We should have been doing that from the start"  He disagreed because he thought the assertion failing meant our code was sending input that was causing a coredump.  I had to show him the actual code from the library and explain to him in very simple terms what an assertion is. Code was something like:

    assert(connection.isActive());
    if(!connection.isActive())
         throw Exception("connection is inactive!");

    Since that monumental undertaking I've pretty much decided that assertions should always be avoided.  Might make testing a little bit harder, but makes dealing with your PHB a little easier.

    The other option is to use assertions for what they were intended. Since an assertion halts the program if a condition doesn't hold true, then you obviously should only use it if you want to stop the program on the condition being false.

    This is really useful for environments such as testing (where you're likely to want to assert that certain things are true all the time). It's not the fault of the assertion that you can't determine what's appropriate in your code.
     



  • @drinkingbird said:

    The other option is to use assertions for what they were intended. Since an assertion halts the program if a condition doesn't hold true, then you obviously should only use it if you want to stop the program on the condition being false.

    Not really; good assertion libraries pop up a dialog box asking "Abort, Debug, Ignore?"  Then the tester can click "Ignore" if the assertion turns out to be not serious.  In the case of an assertion which fires repeatedly (e.g. inside a loop), you can add an additional button for "Ignore this assertion always".



  • @seaturnip said:

    [

    Not really; good assertion libraries pop up a dialog box asking "Abort, Debug, Ignore?"  Then the tester can click "Ignore" if the assertion turns out to be not serious.  In the case of an assertion which fires repeatedly (e.g. inside a loop), you can add an additional button for "Ignore this assertion always".

    Oh yeah? And then the things get compiled into production code and our customers keep calling our helpdesks and throwing swearwords at our employees...



  • Assertions are for internal consistency failures or maybe for failures of method preconditions. In either case they represent a bug somewhere that needs to be fixed. Just ignoring them and getting silent data corruption isn't the right answer. If you can verify that everything will work the way it should even if the assert fails, then that assert shouldn't be there. Also in the "assert(x); if(!x) throw ..." example, if you have exceptions why isn't your assertions library using them? Alternatively, why is the assert there at all if you are going to go and do the check anyway. (or not you but whoever wrote that)



  • @TheRider said:

    @seaturnip said:
    [

    Not really; good assertion libraries pop up a dialog box asking "Abort, Debug, Ignore?"  Then the tester can click "Ignore" if the assertion turns out to be not serious.  In the case of an assertion which fires repeatedly (e.g. inside a loop), you can add an additional button for "Ignore this assertion always".

    Oh yeah? And then the things get compiled into production code and our customers keep calling our helpdesks and throwing swearwords at our employees...

    If a mistake is made that causes those popups to appear in production code, then that same mistake would've caused the regular program-aborting asserts to end up in production code instead, which would be even worse.  Anyway, it isn't especially difficult to disable such things in the release configuration of your project.

    @Talchas said:

    Assertions are for internal consistency failures or maybe for failures of method preconditions. In either case they represent a bug somewhere that needs to be fixed. Just ignoring them and getting silent data corruption isn't the right answer. If you can verify that everything will work the way it should even if the assert fails, then that assert shouldn't be there.

    I never said to ignore them permanently; when they appear they should be fixed as early as convenient.  But in the event that it so happens a build is given to QA that causes a harmless assert when bringing up a certain dialog box, say, the testers should still be able to test the contents of that dialog box.  It's also convenient for developers to be able to skip over assertions at runtime to be able to verify what are the consequences of going past the assertion without needing to comment out the assertion and recompile.



  • @vt_mruhlin said:

    I've seen too many other occurances of "this should never happen", and would like to befriend whoever else shares my sympathies.

    I once put debug messages with rather colourful language into some university coursework for some conditions that I thought it should be impossible to occur.

    Needless to say, blind faith in my own coding ability is something that I've managed to overcome. 



  • @Talchas said:

    Assertions are for internal consistency failures or maybe for failures of method preconditions. In either case they represent a bug somewhere that needs to be fixed. Just ignoring them and getting silent data corruption isn't the right answer. If you can verify that everything will work the way it should even if the assert fails, then that assert shouldn't be there. Also in the "assert(x); if(!x) throw ..." example, if you have exceptions why isn't your assertions library using them? Alternatively, why is the assert there at all if you are going to go and do the check anyway. (or not you but whoever wrote that)

    Yea, I agree. I tend to use asserts mostly for function parameter checks. Say you have a function foo(Object a1). I think it's better to have an assert (a1 != null) : new IllegalArgumentException("a1 must not be null"); right at the beginning, instead of some cryptic NullPointerException deep down in your code. If the assert catches something, that means someone is using your function incorrectly and should check a1 before passing it on to you.
     



  • @Soviut said:

    http://google.com/codesearch?hl=en&lr=&q="shit"&btnG=Search

     There's one part of the way down that reads:

     

    	/* Sun, you just can't beat me, you just can't.  Stop trying,
    * give up. I'm serious, I am going to kick the living shit
    * out of you, game over, lights out.
    */

    The second result was my fave. It links to this:

    double & BaseMatrix :: operator() (INDEX, INDEX)
      {
      (*myerr) << "BaseMatrix: operator() called" << endl;
      return shit;
      }

    double BaseMatrix :: operator() (INDEX, INDEX) const
      {
      (*myerr) << "BaseMatrix: operator() called" << endl;
      return 0;
      }

    BaseMatrix::shit gets initialised to 0 anyway. Pity the class wasn't called Jack.



  • @shadowman said:

    One of those "not responding" popups would always come up and disappear within a few seconds that said in the title bar "End Program - Should not see me."
    I had this, too. IIRC, it was from the VIA chipset drivers.



  • @seaturnip said:

    I never said to ignore them permanently; when they appear they should be fixed as early as convenient.  But in the event that it so happens a build is given to QA that causes a harmless assert when bringing up a certain dialog box, say, the testers should still be able to test the contents of that dialog box.  It's also convenient for developers to be able to skip over assertions at runtime to be able to verify what are the consequences of going past the assertion without needing to comment out the assertion and recompile.

    I guess my point was that there should never be a harmless assert, but if someone screws up, then yeah, it would be good to be able to just skip it.
     



  • @vt_mruhlin said:

    The one good thing about code with no
    reasonable documentation is that you can get programmers arguing with
    each other within comments.  Found this today and had to burst
    into laughter:

    /* this should never happen !  ha, seen that before */

    I wish I knew who added that second part.

    That implies you don't use revision control in your shop, which is even scarier...

    @vt_mruhlin said:

    I've seen too many other occurances of "this should never happen", and would like to befriend whoever else shares my sympathies.  My guess is that, unlike the originator of "this should never happen", my sarcastic friend no longer works here.

    <font size="-1">See also the classic Usenix paper "CANTHAPPEN or /* NOTREACHED */ or Real Programs Dump Core" http://www.literateprogramming.com/canthappen.pdf</font>



  • @DaveK said:

    That implies you don't use revision control in your shop, which is even scarier...

     

    Oh, it gets worse than that.  You're right, some of our code isn't revision controlled.  The stuff that is controlled generally shows the same guy's name on the history.  Not because that guy does a lot of work, but because everybody uses that same login to check their code in and out. 



  • @garyman99 said:

    http://google.com/codesearch?q=%22This+should+never+happen%22&hl=en&btnG=Search+Code

    /* An 1x1 texture couldn't fit for some reason, so
    * break out. This should never happen. But things
    * happen. The disadvantage with this if-statement is
    * that we will never be aware of when this happens
    * since it will silently branch out.
    */

     


Log in to reply