[Python-Dev] with_traceback (original) (raw)

Guido van Rossum guido at python.org
Fri Mar 2 02:23:19 CET 2007

On 2/28/07, James Y Knight <foom at fuhm.net> wrote:

On Feb 28, 2007, at 9:10 PM, Guido van Rossum 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.

I'll say up front that I haven't been paying as much attention to the topic of exception behavior as perhaps I should before attempting to contribute to a thread about it...but... It seems to me that a stack trace should always be attached to an exception object at creation time of the exception, and never at any other time. Then, if someone pre-creates an exception object, they get consistent and easily explainable behavior (the traceback to the creation point). The traceback won't necessarily be useful, but presumably someone pre-creating an exception object did so to save run-time, and creating the traceback is generally very expensive, so doing that only once, too, seems like a win to me.

I agree. Since by far the most common use case is to create the exception in the raise statement, the behavior there won't be any different than it is today; the traceback on precreated objects will be useless, but folks who precreate them for performance reasons presumably won't care; and those that create global exception instances by mistakenly copying the wrong idiom, well, they'll learn quickly (and a lot more quickly than when we try to override the exception).

FWIW, that's basically how exceptions work in Java. From http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Throwable.html: > Instances of two subclasses, Error and Exception, are > conventionally used to indicate that exceptional situations have > occurred. Typically, these instances are freshly created in the > context of the exceptional situation so as to include relevant > information (such as stack trace data).

> A throwable contains a snapshot of the execution stack of its > thread at the time it was created. It can also contain a message > string that gives more information about the error. Finally, it can > contain a cause: another throwable that caused this throwable to > get thrown. The cause facility is new in release 1.4. It is also > known as the chained exception facility, as the cause can, itself, > have a cause, and so on, leading to a "chain" of exceptions, each > caused by another. There's probably a million reasons why this doesn't work for python, but they don't immediately jump out at me. :)

Not at me either. Java exceptions weren't around when Python's exceptions were first invented!

Migration from 2.X to 3.X would consist of recommending not to create an exception outside of a raise line, unless you're okay with the traceback location changing from the raise point to the creation point.

Sounds fine with me. (But I haven't digested Glyph's response.)

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

More information about the Python-Dev mailing list