HN Explorer

33 comments

[ 5.5 ms ] story [ 84.4 ms ] thread
tptacek
It returns false (also in Ruby) --- the "finally" (or "ensure") clause runs after the function body, but before the function epilogue.

It's not really a "paradox" so much as it is very bad style to "return" from a "finally".

Edit

My partner Dave has a much better trick question:

    def foo
        begin
            return false
        ensure
            next
        end
    end
"You win", I told him. "Nah, Google won. But nobody really wins if you write code like that."
ahlatimer
The last trick question doesn't work in Ruby, at least not Ruby 1.8.7. Gives me a "LocalJumpError: unexpected next".

I realize that's not the point, but I figured I'd mention it anyway.

[deleted]
(comment deleted)
notauser
Huh, interesting. The code supplied is:

try { return true; } finally { return false; }

Which returns false. I guess this is because of the guarantee that the finally block will be run, no matter what. The JS interpreter must be catching the return and holding it pending the execution of the finally block.

Checking with

try { return true; } finally { alert('hi'); }

Shows this to be true. (It both returns true AND alerts 'hi'.)

pkulak
I see it that the "finally" is run right before the return. So, the statement "true" would be evaluated, then control would go to the "finally" block, where the method would return false.
huhtenberg
It's just a dumbed down version of Duff's device :-)
docmach
How is this related to Duff's device?
tptacek
It isn't even a very little bit related to Duff's device.
huhtenberg
Simple. It too snips nerds, but only the weaker ones.
zephjc
it's not so mysterious if you know what the intent of a 'finally' block is.
tptacek
I agree; the trickiest thing about it is the confusing relationship between the syntax for exception handling and the syntax for cleanup blocks, which are only vaguely related concepts.
deekayteez
in .NET its illegal - "Control cannot leave the body of a finally clause"
Jupe
It appears MS thought this through. The contrived example is but ONE way a mediocre programmer could really munge this stuff up if the language is not specific about protecting exit points from a finall{} block.
echaozh
What about throwing exceptions in the finally block? Isn't it an exit point too?

When you call non-trivial 3rd party code from your finally block, how do you ensure it doesn't throw? Or what do you do if it does? Indefinitely nested try blocks?

nollidge
Indeed. I can't think of a reason as to why any language would even allow it.
Jach
I know it's horrible in practice, and I really can't see a valid use for this particular case, but forbidding things like this (or other things like multiple inheritance) just because it can be abused has never seemed like a good idea to me.
nollidge
It's not just that it can be abused, though - every use of it is an abuse. Finally{} is not for decisions and manipulating values and program logic, it's for cleaning up resources.
j_baker
It's also worth noting that this won't work in Python before 2.5 (or maybe 2.4).
kevindication
In 2.3 it does. Why wouldn't it?
j_baker
I swear I read that this behavior changed somehow in Python 2.5. But I'm not sure how. But it does at least appear to work in python 2.4.
josephkern
You mean after 2.5 right?

try: return True finally: return False

-- There's an error in your program: * 'return' outside function ...

Just sayin'

paulbaumgart
It works if you put it in a function (2.5.1):

  >>> def test():
  ...  try: return True
  ...  finally: return False
  ... 
  >>> test()
  False
Jach
2.6.2 as well. I liked this little snippet, though I grumbled a little on the inside and would be appalled if I ever found something like that in serious code...
pinstriped_dude
Its a tricky question, but not something I would use to find a "keeper". From the Java tutorial - "The finally block _always_ executes when the try block exits." After the interpreter executes the "return true;" statement, it exits the try block. And then, if you know that "The finally block _always_ executes when the try block exits.", you know that the code block will return false;
blasdel
It's not the answer that makes this a "keeper" screen, but the candidate's progression of facial expressions.
dpcan
A couple things can happen I guess, it depends on the interpreting language.
bantic
I wonder about the merits of this sort of thing as an interview screen, though. There's not necessarily a strong correlation between knowledge of language esoterica and other more important qualities like perseverance and raw intelligence.
blasdel
The point is not to assess language knowledge, but disposition. Even if the candidate is unamused, they should still instantly get what the interviewer found punny about it.
xsmasher
The test is not whether you know the correct answer, but whether your brow furrows when you read the code. If you don't find the snippet interesting you fail.

The ultimate screen would be to follow the candidate home and see if they Google or test the answer.