[Stackless] A question about exceptions

Kristján V. Jónsson kristjan at ccpgames.com
Mon Nov 27 19:18:48 CET 2006


Thanks for your explanation, Christian.
The reason I am thinking of raising the issue more widely is that there are two problems:
1) Exceptions hang around.  In a dispatcher loop, for example, they can exist for a long time.
   Some people consider the resources thus tied up to be a leak.

2) Some (legacy) logging code we have takes a look at the exception state to decide whether
   it should create a traceback from the current location or the exception that it assumes
   is being handled.  If an old and already handled exception is lingering, it prefers that,
   and everyone is confused.

And because of this, the real issue, which annoys me:
The CCP coding guidelines now require everyone to put an sys.exc_clear() in the except: clause
to kill the exception after handling this.

Now, I am fighting this last bit, because it makes you feel like working against the language
rather than with it.  And I think that we should be able to identify the places where we
might run into 1) and 2) above and solve those, rather than to literally litter the code
with this redundant idiom.  But the proponents do have those points, particularly 1) on their
hand, and am somewhat unhappy that an implementaion detail like this can have the effect
of putting some really unintuitive and ugly coding guidelines in place.

Cheers,
Kristján

> -----Original Message-----
> From: stackless-bounces at stackless.com 
> [mailto:stackless-bounces at stackless.com] On Behalf Of Christian Tismer
> Sent: 26. nóvember 2006 21:28
> To: Steve Holden
> Cc: stackless at stackless.com
> Subject: Re: [Stackless] A question about exceptions
> 
> Steve Holden wrote:
> > A pleasure. I'm pretty sure python-dev will tell you to call
> > sys-clear_error() if you don't want the references around.
> 
> There have been several discussions about this, and I 
> remember very well talking to Guido about this as well.
> At some point, it resulted in an not so easy to understand 
> but clear comment in ceval.c, see line 3047 ff.
> 
> It is a little screwed about timing of storage of exceptions, 
> and PyPy does it more straight-forward, since it has no 
> backward-compatibility issues.
> 
> Key point is (from the comment):
> 
>      - Within one frame, sys.exc_ZZZ will hold the last 
> exception caught
>        *in that frame*.
> 
>      - But initially, and as long as no exception is caught in a given
>        frame, sys.exc_ZZZ will hold the last exception caught in the
>        previous frame (or the frame before that, etc.).
> 
> and:
> 
> The invariant is that
>    frame->f_exc_ZZZ is NULL iff the current frame never caught an
>    exception (where "catching" an exception applies only to successful
>    except clauses); and if the current frame ever caught an exception,
>    frame->f_exc_ZZZ is the exception that was stored in 
> tstate->exc_ZZZ
>    at the start of the current frame.
> 
> It is true that an exception could be cleared automatically 
> after it is handled, and it could be discussed.
> 
> The storage in the frame is IMHO confusing and would be 
> clearer if the caller's frame was used, but this doesn't 
> always exist, and since it is possible to produce exceptions 
> without a frame, it would make things even more complicated. 
> But it is true that the exception in a frame does not belong 
> to that frame.
> 
> This is anyway an implementation detail. The interface in 
> question is independent from that, and if it should be 
> possible to raise a dead exception, I don't know, and don't 
> care actually too much.
> 
> cheers - chris
> 
> -- 
> Christian Tismer             :^)   <mailto:tismer at stackless.com>
> tismerysoft GmbH             :     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 802 86 56  mobile +49 173 24 18 776  fax +49 30 
> 80 90 57 05
> PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 
> 57F3 BF04
>       whom do you want to sponsor today?   http://www.stackless.com/
> 
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless
> 

_______________________________________________
Stackless mailing list
Stackless at stackless.com
http://www.stackless.com/mailman/listinfo/stackless



More information about the Stackless mailing list