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.



  •  @dhromed said:

    @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.

    Right, and the point is that the slideshow not working is just that: trivial.  It shouldn't result in something important like login not working.  When the television in the reception room breaks, you don't lock the doors to your entire office building until the repairman comes, do you?

     



  • @dhromed said:

    @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.
    So what you're saying is that it is the JS equivalent to "on error resume next", more or less.



  • @TwelveBaud said:

    @dhromed said:
    @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.
    So what you're saying is that it is the JS equivalent to "on error resume next", more or less.

    Wow. Someone finally gets my point.



  • @blakeyrat said:

    @TwelveBaud said:
    @dhromed said:
    @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.
    So what you're saying is that it is the JS equivalent to "on error resume next", more or less.

    Wow. Someone finally gets my point.

    ??? I do not understand. What exactly happens when "on error resume next" is declared? By the sound of it, I figured that the execution would skip along to the next item or block of code or something and basically ignore the error. But that's not what happens with try{}finally{}; instead, an exception is raised and the call stack starts unwinding back to a point where a catch{} can be found, if any exists. If none exists, the browser halts Javascript execution. Is that what "on error resume next" does? Because it doesn't sound like it and that's confusing.



  • @KattMan said:

    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.

     

    So...what you're saying is...

    ...it's the JS equivalent to "on error resume next", more or less?



  • @lettucemode said:

    @KattMan said:

    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.

     

    So...what you're saying is...

    ...it's the JS equivalent to "on error resume next", more or less?

    Wow, I am astounded, even for TheDailyWTF.  I expect a lot more WTFs in the near future from coworkers of a few of our members.

    Because let's say the third line of code was a save the data call.  With on error resume next the bad data will be saved, with the try-finally it will not be, so NOT EVEN FREAKING CLOSE!



  • @KattMan said:

    Wow, I am astounded, even for TheDailyWTF.  I expect a lot more WTFs in the near future from coworkers of a few of our members.

    Because let's say the third line of code was a save the data call.  With on error resume next the bad data will be saved, with the try-finally it will not be, so NOT EVEN FREAKING CLOSE!

    First of all, tags.

    Secondly, there is often a difference between what a person is saying, and the words they use to say that thing.

    Take a look at this blakeyrat post from before:

    @blakeyrat said:

    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?"

    At this point, a non-pedantic-dickweed can use an amazing deductive ability called "inference" to understand what is really being said. "on error resume next" and the OP's example are practically equivalent because the intent of the programmer writing those things is the same. In both cases, the programmer wants to swallow and ignore errors, which you do in VB with "on error resume next", and in Javascript with an empty catch or finally block. This is made even more clear by blakeyrat's use of "more or less" as a qualifier in each of his posts.

    However, I understand that complicated reasoning skills like "inference" are difficult for pedantic dickweeds. The only way to develop such a skill is to stop being a pedantic dickweed altogether, which I don't know if you're willing to do. When you are ready, climb the mountain, young one. I am waiting at the top.



  • Let me put this another way.

    You have 1000 lines of code.

    Wrap it in "On Error Resume Next"  Line 2 throws an exception, the program will happily ignore it, toss the exception away and continue executing each and every one of the remaining 998 lines of code, some doing thier job, others perhaps throwing other exceptions that are also ignored, some saving data to files, etc, screwing up all kinds of things, then returning to the calling method with no indication of any trouble and the calling method then chugs along.

    Wrap it in a "try-finally", Line 2 throws an exception, the application skips the other 998 lines of code, executes the finally, where in this case it does nothing, then returns to the calling method with an exception to be caught so it knows something went wrong.

    So logically, bitwise and compilation paths and any other way you want to compare them, these two are not even close to similar, if you think they are you should just leave the programming field right now because you are the cause of many of our problems.



  • @KattMan said:

    Let me put this another way.

    You have 1000 lines of blah.

    Wrap it in "On Error Blah Next"  Line 2 throws an exception, the program will happily blah it, toss the exception away and continue blah each and every blah of the remaining 998 lines of blah , some doing blah blah, others perhaps throwing blah blah exceptions blah.

    I know that. We all know that. That's not what I'm...

    Ahh, fuck it.



  • Lettuce...

    You miss the point, there is no Catch here, if there was a Catch, then it would be close to the same.  The exception is never caught in this method it is raised back because it is a finally block only. 

    There couldl be a reason for this as at times there may be some little thing you really want executed at the end regardless of if an exception was thrown but you don't want to actually catch the error and rethrow it.  Yes this is a short hand way of adding a catch and rethrow, but it is not simply a catch and swallow.

     



  • @KattMan said:

    Lettuce...

    You miss the point, there is no Catch here, if there was a Catch, then it would be close to the same.  The exception is never caught in this method it is raised back because it is a finally block only. 

    There couldl be a reason for this as at times there may be some little thing you really want executed at the end regardless of if an exception was thrown but you don't want to actually catch the error and rethrow it.  Yes this is a short hand way of adding a catch and rethrow, but it is not simply a catch and swallow.

     

    The original discussion was never about their functional equivalence. You, sir pedantic dickweed, made it about that.

    EDIT: normal people can still infer meaning even when there are flat-out errors in what was said. I did.



  • @lettucemode said:

    In both cases, the programmer wants to swallow and ignore errors, which you do in VB with "on error resume next", and in Javascript with an empty catch or finally block.

    But ... but that's not right. An empty catch block swallows errors. An empty finally block does nothing. (That's why the pedants are getting so upset. Either that or they just jump at the chance to scorn the un-pangolin.)

    I'm hesitant to reply because this is a stupid thing to keep talking about, but I am very confused at the words being exchanged here and also have otherwise nothing better to do, so...

    EDIT: I guess I should have read and replied faster. Never mind my post, this thread is really stupid.



  • Then what is it? On Error Resume Next is required to handle errors gracefully instead of halting execution?



  • @lettucemode said:

    The original discussion was never about their functional equivalence. You, sir pedantic dickweed, made it about that.

    EDIT: normal people can still infer meaning even when there are flat-out errors in what was said. I did.

    No, Blakeyrat did, in the very first reply, indicating that they were functionally equivilant, which many of us pointed out he was wrong because one causes many unknown hidden side affects whiel the other does not.

    The OP simply posted it with no indication as to what the topic would be.

    Or can't you scroll up and read.



  • @lettucemode said:

    @KattMan said:

    Let me put this another way.

    You have 1000 lines of blah.

    Wrap it in "On Error Blah Next" Line 2 throws an exception, the program will happily blah it, toss the exception away and continue blah each and every blah of the remaining 998 lines of blah , some doing blah blah, others perhaps throwing blah blah exceptions blah.

    I know that. We all know that. That's not what I'm...

    Ahh, fuck it.

    I commend you for trying.



  • @Xyro said:

    @lettucemode said:
    In both cases, the programmer wants to swallow and ignore errors, which you do in VB with "on error resume next", and in Javascript with an empty catch or finally block.

    But ... but that's not right. An empty catch block swallows errors. An empty finally block does nothing. (That's why the pedants are getting so upset. Either that or they just jump at the chance to scorn the un-pangolin.)

    I'm hesitant to reply because this is a stupid thing to keep talking about, but I am very confused at the words being exchanged here and also have otherwise nothing better to do, so...

    EDIT: I guess I should have read and replied faster. Never mind my post, this thread is really stupid.

    Fine. Whatever. I retract that part of that statement that reads ", which you do in VB with "on error resume next", and in Javascript with an empty catch or finally block". My point stands. I agree this is dumb. Let's move on.



  • @lettucemode said:

    I agree this is dumb. Let's move on.

    Yes let's, before we all just get dumb.



  • @KattMan said:

    No, Blakeyrat did, in the very first reply, indicating that they were functionally equivilant

    No. He didn't. He used the phrase "more or less". This is where that "inference" thing I was talking about comes into play.

    EDIT: Ok, fine. done.



  • @KattMan said:

    before we all just get dumb

    Kick dumb in the face!

    [This post was approved by Pirate Batman]



  •  Wait, noone mentioned on error goto (which is what it is more like)?

    Like (err...)

     Sub Marine ()

         on error goto Finally

        ' do some stuff (aka try)

       Finally:

          'nada

     End

     Let the flamewar continue...



  • @serguey123 said:

    @KattMan said:

    before we all just get dumb

    Kick dumb in the face!

    [This post was approved by Pirate Batman]

    I don't know if this is dumb or awesome



  • @pure said:

     Wait, noone mentioned on error goto (which is what it is more like)?

    Like (err...)

     Sub Marine ()

         on error goto Finally

        ' do some stuff (aka try)

       Finally:

          'nada

     End

     Let the flamewar continue...

    Now that is more or less the same.



  • @sprained said:

     @dhromed said:

    @sprained said:

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

    Users are highly unlikely to report anything about the site, especially trivial things like slideshows not working.

    Right, and the point is that the slideshow not working is just that: trivial. 

    I think you missed dhromed's point: you claimed it would be reported because it isn't working; then once he said users would be unlikely to report it because it was a trivial thing,  you've now said that.. the point is it's trivial...

    ... hang on, is this the same route or did we deviate somewhere?



  • @Cassidy said:

    @sprained said:

     @dhromed said:

    @sprained said:

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

    Users are highly unlikely to report anything about the site, especially trivial things like slideshows not working.

    Right, and the point is that the slideshow not working is just that: trivial. 

    I think you missed dhromed's point: you claimed it would be reported because it isn't working; then once he said users would be unlikely to report it because it was a trivial thing,  you've now said that.. the point is it's trivial...

    ... hang on, is this the same route or did we deviate somewhere?

     

     

    Heh, I don't know.  Anyway, wouldn't TRWTF be a website that you couldn't log into because the slideshow was broken?

     



  • @sprained said:

    Heh, I don't know.  Anyway, wouldn't TRWTF be a website that you couldn't log into because the slideshow was broken?
     

    Yeah, that would be TRWTF, because they're unrelated and requiring a lightbox to...

    .. hang on.. shit. You've got me at it now. Damn.



  • @pure said:

     Wait, noone mentioned on error goto (which is what it is more like)?

    Like (err...)

     Sub Marine ()

         on error goto Finally

        ' do some stuff (aka try)

       Finally:

          'nada

     End

     Let the flamewar continue...

    I'd think people more used to the travesty of on error resume next would know that pretty much no other language has it.


  • Winner of the 2016 Presidential Election

    I feel stupider for having to write this, maybe I'm being trolled:

    Effects of On Error Resume Next Effects of try { ... } finally { /* do nothing */ }
    Errors are silently ignored
    Execution continues after an error
    NOTHING, IT'S A NO-OP

    Try {...} finally {} has much more in common with "nothing" than it does On Error Resume Next. On Error Resume Next does something, try finally does nothing.



  • @ASheridan said:

    @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.


    Allman style is strongly discouraged in javascript, due to semicolon insertion (a WTF all on it's own).



  • @joe.edwards said:

    I feel stupider for having to write this, maybe I'm being trolled:

    Likewise@joe.edwards said:

    Effects of On Error Resume Next Effects of try { ... } finally { /* do nothing */ }
    Errors are silently ignored
    Execution continues after an error
    NOTHING, IT'S A NO-OP

    Try {...} finally {} has much more in common with "nothing" than it does On Error Resume Next. On Error Resume Next does something, try finally does nothing.

    In particular, finally { /* do nothing*/ } doesn't catch the exception.

     



  • @ASheridan said:

    @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.

    They're not mutually exclusive, though - the size of the file doesn't bear a resemblance to the readability, more to the maintainability.

    I agree that the size is unimportant - I'd prefer the content to be legible - but with it being so large I'd be concerned about action at a distance when making changes. For that reason I'd look at breaking it up into separate files to limit damage during modifications, but YMMV.

    Suppose I throw this out to others: given the choice, do you prefer monolithic or modular approach?  I know some languages (Java) enforce modular, but I'm curious as to pros/cons of each approach.


Log in to reply
 

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