[Python-Dev] Acquire/release functionality (Was: Extended Function syntax) (original) (raw)

holger krekel pyth@devel.trillke.net
Mon, 3 Feb 2003 14:30:36 +0100

Moore, Paul wrote:

From: holger krekel [mailto:pyth@devel.trillke.net]

> Bernhard Herzog wrote: > > > Alex Martelli <aleax@aleax.it> writes: > > > > > > the exception should be propogated. The problem is that I'm not > > > > sure what is the best way for an except method to signal > > > > that it caught the exception. > > > > > > Maybe the return value of except should be evaluated in a > > > boolean context encoding this? False -> exception not caught, True > > > -> caught ... > > > > except could just reraise the exception if it doesn't handle it. > > This behavior would be similar to that of a normal except clause . > > exactly! The problem in practice is that this means you have to take explicit action to say "I don't know what to do with this". I'd rather it was the other way round, with an empty exception handler def except(self): pass doing nothing (as it looks). If you need to reraise, then this handler silently eats all exceptions. Basically, an empty handler should be the same as no handler. (If for no other reason than to give a subclass a way of disabling the superclass' handler).

With my approach i had all those hooks and except in particular optional. So if you actually wrote 

def __except__(self, type, value, traceback):
    ...

then i presume that you want to check something with the exception (and that's why we should pass it in, btw.).

It's difficult if you have an exception within except because the interpreter would have to keep nested 'exception' information. So delegating the responsibility to except is the cleanest solution IMO. All 'execution' hooks should only handle events (enter/leave/except) but not push something back because it really complicates matters.

Actually, it's clear to me that the controversial issues are:

1. Multiple expressions in one with clause 2. Exception handling Maybe the simplest answer is to remove both of these options, and stick with a slimmed down version which does gthe basics well. Does anyone have a good use case for either of these features?

Meanwhile i made a proposal in a new thread where i have some use cases. I am pretty sure that stating exception behaviour up-front is not YAGNI. At least for the xml-case there is a very nice use case (which i use in another project):

XYZ html.tr():
    XYZ html.td():  compute_column()

now the html.td() handler can locally catch an exception and present an error-link which leads to a page containing more information and a traceback. Imagine you have to do this with inline try-except clauses: you don't and then you get long meaningless tracebacks with hardly any context what went wrong.

With the aid of the except hook you can still render the non-erranonous part of the page and give an immediate clue what went wrong and where. So I think except has the potential to improve error-handling by abstracting it out into a method instead of (redundantly) intermingling it with every thunk.

regards,

holger