> def f():
> for i in range(10):
> print i
> try:
> return
> finally:
> break
> print 999
>
> where the finally clause nullifies the return. In a generator, a yield
> in the finally clause still needs to be dealt with somehow.
>
>
>
On 8/23/06, Phillip J. Eby wrote:
> Our original
> assumption was that if they could implement throw() then they could clearly
> implement close(), since close() was defined in terms of throw(). An
> asynchronous return might be another matter.
Such asynchronous return can always be implemented v
On 8/23/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Simpler is in the eye of the beholder - the current close() merely uses
> throw() to raise a particular kind of exception 'asynchronously' (which is
> already a familiar concept due to KeyboardInterrupt). What you're suggesting
> is a completely
Consider the following example:
for i in range(3):
try:
print i
break
except:
print "Unexpected exception!"
finally:
print "Finally"
When executed, it naturally prints
0
Finally
since break does not use exceptions to transfer the control and as
such can not be stopped us
