On 3/2/07, Andrew Dalke <[EMAIL PROTECTED]> wrote:
> On 3/2/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > This has given me another idea:
> ...
> > Now, I'm not proposing that the raise statement should
> > actually have the above syntax -- that really would be
> > a step backwards. Instead it would be required to have
> > one of the following forms:
> >
> > raise ExceptionClass
> >
> > or
> >
> > raise ExceptionClass(args)
> >
> > plus optional 'with traceback' clauses in both cases.
> > However, the apparent instantiation call wouldn't be
> > made -- it's just part of the syntax.
>
> Elsewhere here I listed several examples of existing
> code which raises an instance which was caught or
> created earlier. That would not be supported if the
> raise had to be written in your given forms.
Raising an instance that was just caught or created a bit earlier
should definitely be supported. Especially this pattern is useful, in
all its variations:
def handle_error(self, exc):
"""Subclass can override to ignore it."""
raise exc
def foo(self):
if self.bar():
self.handle_error(RuntimeError("can't foo because of bar"))
# if it returns, ignore bar
# do foo's thing
The question is, how to distinguish this from an exception created
*much* earlier and raised repeatedly? Adding an attribute pointing to
the "owning thread" might help catch concurrent use, but that wouldn't
help if the pattern is used in a single-threaded environment, even
though it could still be an error there (e.g. in used in a recursive
context).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
