Finally nada



  • From a JavaScript file in our codebase:


    Line 690:

        try {
    

    lines 985-987:

        } finally {
          // nada
        }
    

    (Yes, it's the same try block.)



  • That would be the JS equivalent to "on error resume next", more or less.



  • @Mason Wheeler said:

    From a JavaScript file in our codebase:


    Line 690:

        try {
    

    lines 985-987:

        } finally {
          // nada
        }
    

    (Yes, it's the same try block.)

    You have javascript files with more than 900 lines. It must be wonderful to work in your company.



  • @Speakerphone Dude said:

    You have javascript files with more than 900 lines. It must be wonderful to work in your company.
    That in itself is not necessarily a problem, particularly if you code in the Allman style and put braces on their own line so they line up. I'd much rather have a code file that's double the number of lines if it is more readable.



  • @blakeyrat said:

    That would be the JS equivalent to "on error resume next", more or less.

    Avtually it isn't.  On Error Resume Next will actually keep executing lines of code until you have a complete cluster fuck of munged data.  At least with teh Javascript, it will fall to the finally on the first error without executing anything more, yes the error is swallowed silently and nothing is done with it, but at least in this function you don't have munged up data, doesn't mean the calling function won't munge it up though.



  • @KattMan said:

    @blakeyrat said:

    That would be the JS equivalent to "on error resume next", more or less.

    Avtually it isn't. On Error Resume Next will actually keep executing lines of code until you have a complete cluster fuck of munged data. At least with teh Javascript, it will fall to the finally on the first error without executing anything more, yes the error is swallowed silently and nothing is done with it, but at least in this function you don't have munged up data, doesn't mean the calling function won't munge it up though.

    So what you're saying is that it is the JS equivalent to "on error resume next", more or less.



  • @Mason Wheeler said:

    From a JavaScript file in our codebase:


    Line 690:

        try {
    

    lines 985-987:

        } finally {
          // nada
        }
    

    (Yes, it's the same try block.)

    A 295 lines long try block? What the heck, what exactly is being done there?



  • @blakeyrat said:

    So what you're saying is that it is the JS equivalent to "on error resume next", more or less.

    No, it's nothing like "on error resume next".  If that had been a catch {//nada} block, it would be (kind of), but this is a finally block, which is basically a (relatively) expensive no-op.

     



  • @Mason Wheeler said:

    @blakeyrat said:
    So what you're saying is that it is the JS equivalent to "on error resume next", more or less.

    No, it's nothing like "on error resume next". If that had been a catch {//nada} block, it would be (kind of), but this is a finally block, which is basically a (relatively) expensive no-op.

    So what you're saying is that it is the JS equivalent to "on error resume next", more or less.

    BTW this is a fascinating look into the pedantic dickweed mind. A normal non-dickweed would probably go, "let's see a couple of lines added so the programmer doesn't have to deal with errors even though it could lead to data corruption further on... yeah, that's pretty goddamned similar to 'on error resume next' isn't it?"

    Meanwhile the pedantic dickweed mind is going, "THOSE TWO CODE CONSTRUCTS DO NOT COMPILE TO THE EXACT SAME MACHINE CODE THEREFORE THEY ARE WILDLY DIFFERENT I AM A ROBOT BEEP BEEP ALSO WHAT DOES MORE OR LESS MEAN I DO NOT UNDERSTAND BUT ROBOTS DO NOT ASK HUMAN UNITS FOR CLARIFICATION"

    I have no idea how to cure this disease; I can only point out the symptoms.



  • @blakeyrat said:

    @Mason Wheeler said:
    @blakeyrat said:
    So what you're saying is that it is the JS equivalent to "on error resume next", more or less.

    No, it's nothing like "on error resume next". If that had been a catch {//nada} block, it would be (kind of), but this is a finally block, which is basically a (relatively) expensive no-op.

    So what you're saying is that it is the JS equivalent to "on error resume next", more or less.

     

    No. I'm saying it is NOTHING AT ALL LIKE "on error resume next" in any way.  Do you seriously not know the difference between try/catch and try/finally?  If you did, that would be obvious.

     



  • @blakeyrat said:

    @Mason Wheeler said:
    @blakeyrat said:
    So what you're saying is that it is the JS equivalent to "on error resume next", more or less.

    No, it's nothing like "on error resume next". If that had been a catch {//nada} block, it would be (kind of), but this is a finally block, which is basically a (relatively) expensive no-op.

    So what you're saying is that it is the JS equivalent to "on error resume next", more or less.

    No, because this doesn't "resume next". It doesn't resume at all. If an exception is thrown, the script crashes and execution does not continue. It does the exact same thing it would do if the try/finally wasn't there at all. You're getting "finally" and "catch" confused.



  • The deseise is yours Blakey.

    Heres the deal.

    Just to make it simple I'm not going to use real code, because it doesn't matter.  Let's say you have three lines of code and the second one throws an exception.

    With on error resume next you move on and execute the third line of code and any and all lines after that, possibly throwing more exceptions that are contually ignored.

    With this try-finally blovk, you skip the third line of code and fall right into the finally which does nothing else. 

    These are two different behaviours.  As I said, you still have a swallowed exception but the code execution has not happened the same.  On error resume next is worse, but this is still bad.

     



  • @blakeyrat said:

    @Mason Wheeler said:
    @blakeyrat said:
    So what you're saying is that it is the JS equivalent to "on error resume next", more or less.

    No, it's nothing like "on error resume next". If that had been a catch {//nada} block, it would be (kind of), but this is a finally block, which is basically a (relatively) expensive no-op.

    So what you're saying is that it is the JS equivalent to "on error resume next", more or less.

    BTW this is a fascinating look into the pedantic dickweed mind. A normal non-dickweed would probably go, "let's see a couple of lines added so the programmer doesn't have to deal with errors even though it could lead to data corruption further on... yeah, that's pretty goddamned similar to 'on error resume next' isn't it?"

    Meanwhile the pedantic dickweed mind is going, "THOSE TWO CODE CONSTRUCTS DO NOT COMPILE TO THE EXACT SAME MACHINE CODE THEREFORE THEY ARE WILDLY DIFFERENT I AM A ROBOT BEEP BEEP ALSO WHAT DOES MORE OR LESS MEAN I DO NOT UNDERSTAND BUT ROBOTS DO NOT ASK HUMAN UNITS FOR CLARIFICATION"

    I have no idea how to cure this disease; I can only point out the symptoms.

    Pseudocode:

    on error resume next;

    int x = 2 / 0;

    print "this line will be printed out".

    vs.

    try

    {

    int x = 2 / 0;

    print "this line will NOT be printed out".

    }

    finally

    {

    }

    Yup, they are *exactly* the same.



  • The trouble is that many uses of Javascript essentially require "on error resume next".  Most browsers will stop executing any further javascript on the page if they encounter any exception in any script.  But you might have one script that handles your rich drop-down menus and a different one that handles your AJAX login form, and another that runs the slideshow, and another to show/hide the annoying floating social media tab that the client insisted on -- and you wouldn't want a failure in one of those (which often happens due to a poorly coded browser extension/user script, or occasionally a browser upgrade, or because the idiot client asked his nephew to make a quick change that happened to remove an HTML element that the script depended on) to interfere with the others.

    So it's not unusual or even totally unreasonable to wrap a large block of javascript in a try/catch block with nothing in the catch block because you want it to fail silently.  You're essentially saying "don't break the login form if the user's installed something that keeps the slideshow from working".  Why have an empty finally block, though, I don't know.



  • @KattMan said:

    With this try-finally blovk, you skip the third line of code and fall right into the finally which does nothing else. 

    ...As I said, you still have a swallowed exception but the code execution has not happened the same.  On error resume next is worse, but this is still bad.

     

    This point was made above, but "finally" does not swallow the exception. Instead, as I think we all know but sometimes I just have to say the obvious, it guarantees that a block will be entered whether or not an exception was thrown. Any exceptions still get thrown.

    But the "nada" comment after 900 lines of suspense is nonetheless damned anti-climactic.



  • @blakeyrat said:

    So what you're saying is that it is the JS equivalent to "on error resume next", more or less.
     

    The code doesn't resume next on error.



  • @LegacyCrono said:

    @Mason Wheeler said:

    From a JavaScript file in our codebase:


    Line 690:

        try {
    

    lines 985-987:

        } finally {
          // nada
        }
    

    (Yes, it's the same try block.)

    A 295 lines long try block? What the heck, what exactly is being done there?

    Read ASheridan reply to a similar comment I made before. The answer is that putting curly braces on a new line makes files with 900+ lines of codes acceptable because that's what some gay dude who wrote the biggest spam engine ever used to do. Or something.



  • @sprained said:

    So it's not unusual or even totally unreasonable to wrap a large block of javascript in a try/catch block with nothing in the catch block because you want it to fail silently.
     

    If things break, it comes back to me and I can fix it.

    If they don't break, they never get reported and you have a broken thing that you'll never know about, for ever and ever.

    So yeah.

    empty catch block.

    Excellent pattern.



  • @dhromed said:

    @sprained said:

    So it's not unusual or even totally unreasonable to wrap a large block of javascript in a try/catch block with nothing in the catch block because you want it to fail silently.
     

    If things break, it comes back to me and I can fix it.

    If they don't break, they never get reported and you have a broken thing that you'll never know about, for ever and ever.

    So yeah.

    empty catch block.

    Excellent pattern.

     

    It does get reported because the slideshow isn't working.  But you don't get a bunch of irate users who can't log in.

     



  • @sprained said:

    It does get reported because the slideshow isn't working.
     

    Yes, when the client founds out on his/her own in 6 months. Users are highly unlikely to report anything about the site, especially trivial things like slideshows not working.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.