Guido van Rossum
guido at python.org
Fri Mar 2 02:32:10 CET 2007
On 2/28/07, glyph at divmod.com <glyph at divmod.com> wrote:
> On Wed, 28 Feb 2007 18:10:21 -0800, Guido van Rossum <guido at python.org> wrote:
> >I am beginning to think that there are serious problems with attaching
> >the traceback to the exception; I really don't like the answer that
> >pre-creating an exception is unpythonic in Py3k.
> In Twisted, to deal with asynchronous exceptions, we needed an object to specifically represent a "raised exception", i.e. an Exception instance with its attached traceback and methods to manipulate it.
> You can find its API here:
> Perhaps the use-cases for attaching the traceback object to the exception would be better satisfied by simply having sys.exc_info() return an object with methods like Failure? Reading the "motivation" section of PEP 344, it describes "passing these three things in parallel" as "tedious and error-prone". Having one object one could call methods on instead of a 3-tuple which needed to be selectively passed on would simplify things.
> For example, chaining could be accomplished by doing something like this:
> I can't think of a good name for the new object type, since "traceback", "error", "exception" and "stack" all already mean things in Python.
I'm guessing you didn't see James Knight's proposal. If we can agree
on more Java-esque exception semantics, the exception object could
serve this purpose just fine.
I'm thinking that in that case an explicit with_traceback(tb) should
perhaps clone the exception; the clone could be fairly simple by
constructing a new uninitialized instance (the way unpickling does)
and filling its dict with a copy of the original's dict, overwriting
the traceback. (Also, if Brett's exception reform is accepted, we
should call this attribute just traceback, not __traceback__.)
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev