[Stackless] A question about exceptions

[Kristján V. Jónsson]

You are right that the memory really isn't all that bad, although
if one isn't careful once can easily construct circular references
through the exception object.

In that sense, I don't mind having the exception floating around,
and I can clear it manually when in dispatching loops that execute
code and handle exceptions, over and over again.

But it would be really useful to be able to tell if we are in
an "handling context", or if the exception has been handled.
Maybe an additional flag in sys would do the trick?

Of course, we have had no problem with the
try:
	foo()
except:
	bar()
	sys.exc_clear()

semantics.  Doing it that way appears to have no ill effects in our rather
large codebase (except for annoying me), so I wonder why this simply
isn't the default.

Kristján

> -----Original Message-----
> From: Christian Tismer [mailto:tismer at stackless.com] 
> Sent: 28. nóvember 2006 00:14
> To: Kristján V. Jónsson
> Cc: Steve Holden; stackless at stackless.com
> Subject: Re: [Stackless] A question about exceptions
> 
> Kristján V. Jónsson wrote:
> > 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.
> 
> Ok. OK, but...
> 
> > 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.
> 
> I think this is a delicate issue, and they will pull good 
> reasons in, why this must be exactly so. If necessary by the hairs.
> So please be aware of fighting wooden heads and shoes. :-)
> 
> No, we need really good arguments, but I also found this 
> annoying for a long time. But a good example why this is bad 
> is good to have.
> 
> The leakage is a bit hard to argue about; it is just one 
> exception in a frame. If this creates a huge memory problem, 
> you might also be asked to re-think your design.
> 
> The logging code might check if the exception is handled.
> Maybe what we need is a better way to distinguish if it is 
> handled or not? Or do you do logging of exceptions, whether 
> handled or not? Maybe we should first try to identify what is 
> really best to have before going for the war.
> 
> cheers - chris     (of course it is a wart but not an easy one)
> 

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