On Tue, Feb 28, 2012 at 4:48 PM, Tom Boutell <t...@punkave.com> wrote:
> On Tue, Feb 28, 2012 at 11:32 AM, Kiall Mac Innes <ki...@managedit.ie>
> wrote:
> > Yes, You could abstract the try/catch into a new (and un-needed) function
> > to try and emulate the behavior of finally.. Unless, for example, you
> > re-throw the exception after logging in the catch.
>
> 'finally' doesn't run for stuff that throws an exception not caught in
> the try { } block, or an exception thrown again in the catch { } block
> - does it?
>
> I would hope not, since that means "something this block of code did
> not anticipate at all - another sort of exceptional situation
> altogether" and really should not run any more local code, nothing
> until and unless there is a catch block somewhere further up that does
> catch that exception.
>
I would indeed expect the finally to run regardless of what happens in the
catch block.
$ python
>>> def divide(x, y):
... try:
... result = x / y
... except ZeroDivisionError:
... print "division by zero!"
... raise Exception('division by zero')
... else:
... print "result is", result
... finally:
... print "executing finally clause"
...
>>> divide(2, 1)
result is 2
executing finally clause
>>>
>>> divide(2, 0)
division by zero!
executing finally clause <====== The interesting part
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 6, in divide
Exception: division by zero
>>>
>>> divide("2", "1")
executing finally clause
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in divide
TypeError: unsupported operand type(s) for /: 'str' and 'str'
