Return vs. Finally (2)

re: Return vs. Finally (2)

.NET Junkie — Mon, 17 Dec 2007 11:39:17 GMT

I'm very curious. How does the IL look like that IronPython generates?

re: Return vs. Finally (2)

Niki — Mon, 17 Dec 2007 12:55:50 GMT

Python: return self.i++

class Sample:

def meth(self):

try:

return self.i

finally:

self.i += 1

re: Return vs. Finally (2)

StewartT — Mon, 17 Dec 2007 13:01:22 GMT

If you treat the IL finally block as the moral equivalent of C++'s automatic destructor calls, then C++ has a hybrid of the two, where it is not possible to return from a "finally" block, since there is no where to put the return statement, however it is possible to throw. In C++ the consensus seems to be that throwing from destructors is a "bad thing"(TM), and I have only ever had cause to do it when writing classes expressly designed to do it as part of dynamic exception generation (don't ask :)). It is particularly dodgy in C++ of course due to the amusing C++ double fault behaviour, where if you throw from a destructor during an exception unwind, std::terminate is called and the process is to all intents and purposes dead, however you cannot know at the time when you throw that this is going to happen.

I'm not saying its right, but I thought it was another perspective i'd point out.

re: Return vs. Finally (2)

jmstall — Mon, 17 Dec 2007 21:01:44 GMT

Stewart - good point about C++, that would have been good for me to include at the top.

Niki - yeah, that's another twisted example. That's similar to what I blogged about before, and C# has similar behavior.

.NET Junkie: basically, you can build a finally block with try/catch blocks + rethrow. It's clunkier, and the stack-unwinding is worse under a debugger/watson, but it gives you much finer control.