[Python-Dev] Another traceback idea [was: except Exception as err, tb]

[Guido van Rossum]

On 3/2/07, Andrew Dalke <dalke at dalkescientific.com> wrote:
> On 3/2/07, Greg Ewing <greg.ewing at canterbury.ac.nz> 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/)