On Sat, May 31, 2008 at 11:41 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Adam Olsen <rhamph <at> gmail.com> writes:
>> > By the way, another interesting sys.exc_info() case:
>> >
>> > def except_yield():
>> > try:
>> > raise TypeError
>> > except:
>> > yield 1
>> >
>> > def f():
>> > for i in except_yield():
>> > return sys.exc_info()
>> >
>> > Right now, running f() returns (None, None, None). But with rewritten
> exception
>> > stacking, it may return the 3-tuple for the TypeError raised in
> except_yield().
>>
>> What exception stacking? I thought we'd be using a simple per-thread
>> exception. I'd expect the yield statement to clear it, giving us
>> (None, None, None).
>
> There is a per-thread exception for the current exception state but we
> must also save and restore the previous state when we enter and leave
> an exception handler, respectively, so that re-raising and sys.exc_info()
> work properly in situations with lexically nested exception handlers.
The bytecode generation for "raise" could be changed literally be the
same as "except Foo as e: raise e". Reuse our existing stack, not add
another one.
sys.exc_info() won't get clobbered until another exception gets
raised. I see no reason why this needs to return anything other than
(None, None, None):
def x():
try:
...
except:
try:
...
except:
pass
#raise
return sys.exc_info()
The commented out raise should use the outer except block (and thus be
lexically based), but sys.exc_info() doesn't have to be. If you want
it to work, use it *immediately* at the start of the block.
> Also, "yield" cannot blindingly clear the exception state, because the frame
> calling the generator may except the exception state to be non-None.
> Consequently, we might have to keep the f_exc_* members solely for the
> generator case.
Why? Why should the frame calling the generator be inspecting the
exception state of the generator? What's the use case?
--
Adam Olsen, aka Rhamphoryncus
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
