[Python-3000] sys.exc_info()

Adam Olsen rhamph at gmail.com
Sat May 31 21:35:36 CEST 2008


On Sat, May 31, 2008 at 11:41 AM, Antoine Pitrou <solipsis at pitrou.net> 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


More information about the Python-3000 mailing list