On 2/28/07, James Y Knight <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
