[Python-Dev] Exception masking/chaining

Guido van Rossum guido@python.org
Thu, 12 Jun 2003 09:48:37 -0400


> > More globals of course defeat the purpose (one of the reasons for
> > putting the traceback in the exception is to get rid of
> > sys.exc_traceback).
> 
> I think the idea was that this would be a C-level global,
> not a Python one (i.e. part of the existing group of
> C variables representing the current exception state).

Possibly, except those aren't globals either (they're members of the
per-thread state record).

> > I also think that doing this automatically whenever PyErr_Set*() is
> > called would cause a lot of spurious tracebacks.  (Unless the idea is
> > to skip the chaining if the original exception has an empty
> > traceback
> 
> I don't understand that. What is a "spurious" traceback? And how
> are you going to get one if the current traceback is empty?

I was imagining that the default mechanism for printing tracebacks
would always try to follow the chain of tracebacks, and report not
just the traceback, but also the exception that was replaced.  There's
a lot of C code out there that catches e.g. AttributeError and
replaces it with a more specific error (e.g. BifurcationError("can't
bifurcate the sploorg") replacing AttributeError("__bifurcate__").
I think this would cause end user confusion.

> > I worry about backwards compatibility.
> 
> What would this break? Code which doesn't know about chained
> exceptions can just ignore the new attribute and get exactly
> the information they used to get from the exception and its
> traceback, as far as I can see.

I didn't mean code breakage, but the above change in output.

--Guido van Rossum (home page: http://www.python.org/~guido/)