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

Greg Ewing greg.ewing at canterbury.ac.nz
Fri Mar 2 23:00:53 CET 2007


Nick Maclaren wrote:

> The instance contains all of the information about the details, such
> as the exact operation, the values and the context (including the
> traceback).  It CAN'T be an object, because it is not 'assignable'
> (i.e. a value) - it is inherently bound to its context.  You can
> turn it into an object by copying its context into an assignable form,
> but the actual instance is not assignable.

This has given me another idea:

Instead of instantiating the exception when it's raised,
what about instantiating it when it's *caught* instead?

Suppose for a moment that we take what might seem to be
a retrograde step, and go back to the old way of raising
exceptions, where you supply the type and arguments
separately:

    raise MyException, ("Bogus value:", x)

Now instead of immediately "normalising" this by creating
the exception, we keep all three parts (type, args, traceback)
separate while we search for a handler.

If we find one of the form

    except MyException as e:

then at that point we instantiate the exception, attach the
traceback and assign it to e.

However, if we find one of the form

    except MyException:

then we don't need to instantiate it at all! This would
address the issue of efficiently using exceptions for flow
control, since for that kind of use you're probably not
going to want the exception object, in which case your
except clauses will be of the latter form.

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.

--
Greg


More information about the Python-Dev mailing list