• (nodebb)

    Today I learnt that you can actually a return statement in the finally branch in Java (I guess). What a weird language.

    Addendum 2025-02-12 06:47: BTW someone here more into Java these days around and can me explain what is going on?

    Is there always returned null no matter what in this case?

    Is finally in this case only executed when an exception happens?

    Or is there some magic condition happening and it doesn't execute the return code but the original one in case there is not exception? How would that even work if the code is more complex though?

  • Zatapatique (unregistered) in reply to MaxiTB

    And considering that the finally branch is always executed, what will be returned when creating the connection succeeds? Will it return the connection or will it return null?

  • Jurarigo (unregistered)

    The real problem is that the finally block will ALWAYS return null, no matter what. It doesn't matter if the connection fails or succeed because the method will only give you a piece of the void living on the author of this code's head.

  • Rob (unregistered)

    A return or throw in a finally block will discard anything that's returned or thrown from a try or catch block. In other words, this code will always return null, and nothing else.

  • Maarten (unregistered)

    This code attempts to create a connection, and if it fails for any reason, it logs an error and returns null.

    You're missing the essence here for what a return statement in a finally block does in Java. It will actually override the previous return value, so even if it doesn't fail while creating the connection, it will still return null.

    The only reason this could have been successfully tested (I'm not going to speculate on what the success criteria were for those test) is if the testers actually followed the instruction to uncomment the other return statement in the finally block.

  • Hans (unregistered)

    I was wondering what would happen in C# (as I suspected that finally's return would overwrite the previous one), so I tried a return in both the try and the finally. However the compiler wouldn't let me: "CS0157 Control cannot leave the body of a finally clause". It sort of confirms my opinion of Java

  • (nodebb)

    TRWTF is Java. I usually try not to poo-poo on it (me mainly being a C# dev), but this is just so wrong. Like, people who maintain Java should accept a hard compilation error break across the ecosystem and make returns inside finally blocks illegal. It's that bad.

  • (nodebb)

    I worked at a place (not my dept) where it was discovered that for year anyone with certain punctuation in their name always failed on the checkout page with an exception, which was logged each time - but no one ever looked at the logs. So for the lack of looking at logs, lots of revenue was lost.

  • (nodebb) in reply to Hans

    Presumably that means that a finally block mustn't leak exceptions either.

  • Smithers (unregistered)

    Good timing on this one. Python, like Java, currently has return in a finally: block override any return in the try:. But just last week the Steering Council accepted "PEP 765 – Disallow return/break/continue that exit a finally block", which will make this produce a warning and perhaps, someday, an error.

  • (nodebb) in reply to mynameishidden

    Of course there are umpteen thousands of trolls all over the Internet posting fake stories, but I have no trouble at all believing this. I've not only seen plenty of development shops, I've seen plenty of production environments and the people who staff them. Admins noticing the problem would be the exception, not the rule.

  • (nodebb)

    What made you think this is Java? Pfft. It is NOT Java. Java requires a throws-statement for Exception.

    Though, if it had been Java, I'd repackaged it in a runtime exception and thrown that... problem solved.

  • bambam (unregistered)

    What is the ... in SqsClient.builder() ... .build() ?

  • TrueWill (unregistered)

    I tried it with JavaScript (with some modifications); that also returns null (always).

  • SG (unregistered)

    Could be worse... at least they're logging the exception, stacktrace included. I mean, that's just about the only thing they've done right, but still...

  • (nodebb) in reply to Rob

    I'm flabbergasted. I've been coding in Java for quite a very long time and thought I knew it inside out. Yet I had no idea that 1/ a return in a finally was even possible, and 2/ that it would override the return in the try section (per the various comments).

    I'd have expected this to be a control flow error rejected by the compiler -- the same way the compiler rejects code after a return statement in a block, which is exactly what a finally does.

    I realize I never even thought of ever coding something that way, not even out of curiosity.

  • Rob (unregistered) in reply to Erik

    What made you think this is Java? Pfft. It is NOT Java. Java requires a throws-statement for Exception.

    It is very much Java. The reason why you don't see a throws statement is because no exception is thrown from this piece of code. If any exception occurs at all it's in the building of the SqsClient. Such an exception is then logged but otherwise discarded.

  • Loren Pechtel (unregistered)

    I believe the intent was to have it die in testing if it couldn't work, but somebody demanded that in production it do what it can when whatever this is failed rather than take the time to figure out what the real problem was.

Leave a comment on “Finally, a Null”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article