[Python-3000] sys.exc_info()

Adam Olsen rhamph at gmail.com
Sun Jun 1 00:28:15 CEST 2008


On Sat, May 31, 2008 at 2:03 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Adam Olsen <rhamph <at> gmail.com> writes:
>>
>> 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.
>
> As someone else pointed, there is a difference between the two constructs: the
> latter appends a line to the traceback while the former doesn't. I suppose in
> some contexts it can be useful (especially if the exception is re-raised several
> times because of a complex architecture, e.g. a framework).

Yeah.  If anything it seems like a positive, not a negative.


>> The commented out raise should use the outer except block (and thus be
>> lexically based), but sys.exc_info() doesn't have to be.
>
> But would you object to sys.exc_info() being lexically based as well?
> I say that because the bare "raise" statement and sys.exc_info() use the same
> attributes internally, so they will have the same semantics unless we decide
> it's better to do otherwise.

I'm trying to eliminate complexity, paring it down to the bare minimum
of supported functionality.  However, I was also confusing
sys.exc_info() with sys.last_*.  That leads to another thought..


>> > 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?
>
> You misunderstood me. The f_exc_* fields will be used internally to swap between
> the inner generator's exception state and the calling frame's own exception
> state. They will have no useful meaning for outside code so I suggest they are
> not accessible from Python code anymore.

Why not move f_exc_* into the PyTryBlock struct?  We can eliminate the
per-thread exception and have sys.exc_info() search the stack for an
active except block.  No need to swap anything because the stack is
always current.

(tstate->curexc_* would be unchanged of course, as it represents the
"hot" exception, not the last caught exception.)


-- 
Adam Olsen, aka Rhamphoryncus


More information about the Python-3000 mailing list