[Python-Dev] Traceback problem

[Christian Tismer]

Kevin Jacobs wrote:
...

> I've uploaded a patch to SF:
> 
>   http://www.python.org/sf/693195
> 
> It turns out that ceval.c:reset_exc_info was a red herring and did not do
> what we wanted.  Luckily, the correct behavior is fairly trivial (although
> the interaction between set_exc_info and reset_exc_info had me seeing
> cross-eyed for a few minutes).

I had a look at your patch.

Here a small analysis:

In essence, it is doing exactly the same
as PyErr_Restore(NULL, NULL, NULL) from errors.c,
with the difference that it is acting on
sys.exc_(type, value, traceback) instead of
sys.curexc_(type, value, traceback).

I just want to make sure that this is what we want to do.

The rest of reset_exc_info restores an exception that
has been captured in the frame, before.

The counterpart is set_exc_info, which is called only
if an exception handler is executed. The frame then
saves a prior exception from tstate to local variables
and sets a new exception into tstate.
I have no real clue what should happen if this
occours multiple times -- the frame will only accept
one such exception to save.
Ah, I see: This is meant to be an exception which
originated in the caller of the function, and the frame
is just supposed to save the caller's exception, in
case it is itself called in an exception handler!

The action on return is to drop the current exception,
since it has been handled, and to restore the caller's
exception, if this exists.

There is also a small trick here:
set_exc_info assigns Py_None to tstate->exc_type, if
it has been NULL. This is then assigned to the local
variables of the frame. The side effect of this trick is,
that after set_exc_info has been called once, reset_exc_info
always will think that it has to restore, even if there
is just a None-Exception. The side effect is, that the
frame's variables always will be cleared out on a return.

Well, this code could stand a few more comments ;-)

Ok, what I understood now is, that this extra action of
reset_exc_info is really not what we need here, this is
about restoring the caller's exception. But we are not
concerned with the caller here, since we stay in the
current frame.

We just want to clear the current exception in tstate,
and I think your code does the right thing.

+1

cheers -- chris

p.s.: I would probably have done the exception saving
in the caller's frame, where it belongs, IMHO.

-- 
Christian Tismer             :^)   <mailto:tismer@tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/