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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4