- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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?
Admin
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?
Admin
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.
Admin
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.
Admin
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.
Admin
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 thefinally
. However the compiler wouldn't let me: "CS0157 Control cannot leave the body of a finally clause". It sort of confirms my opinion of JavaAdmin
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.
Admin
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.
Admin
Presumably that means that a finally block mustn't leak exceptions either.
Admin
Good timing on this one. Python, like Java, currently has
return
in afinally:
block override anyreturn
in thetry:
. 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.Admin
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.
Admin
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.
Admin
What is the ... in SqsClient.builder() ... .build() ?
Admin
I tried it with JavaScript (with some modifications); that also returns null (always).
Admin
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...
Admin
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.
Admin
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.
Admin
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.