[Summary: James Knight's idea can't work unless we copy the entire stack, which is bad. Disregard my previous posts in this thread of a few minutes ago. See the end of this post why.]
On 3/1/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > James Y Knight wrote: > > > It seems to me that a stack trace should always be attached to an > > exception object at creation time > > Um. Yes. Well, that's certainly an innovative solution... In the Python context perhaps, but given the Java precedent I would hardly call it innovative. > > The traceback won't necessarily be *useful*, > > Almost completely use*less*, I would have thought. > The traceback is mostly used to find out where > something went wrong, not where it went right (i.e. > successful creation of the exception). Which is one opcode before it is raised, in 99.99% of all cases. > > creating the traceback is generally very expensive, > > I don't think so -- isn't it just a linked list > of existing stack frames? That should be very cheap > to create. This is a difference between Python and Java that we should preserve. Java's traceback is a string; Python's is a linked list of traceback objects > > From http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Throwable.html: > > > >>A throwable contains a snapshot of the execution stack of its > >>thread at the time it was created. > > This would be a major and surprising change to Python > users. > > It would also be considerably *more* expensive to implement > than the current scheme, because it would require copying the > entire stack, instead of just linking stack frames together > as they are unwound during the search for an exception > handler. Oh bah, you're right. This sounds like a deal killer c.q. show shopper. In my earlier responses forgot the details of how Python exceptions work. You start with a traceback object pointing to the current frame object (traceback objects are distinct from frame objects, they are linked in the *opposite* direction, so no cycles are created); then each time the exception bubbles up a stack frame, a new traceback object pointing to the next frame object is inserted in front of the traceback. This requires updating the traceback pointer each time we bubble up a frame. Then when you catch the exception, the chain of tracebacks points to all frames between the catching and the raising frame (I forget whether catching frame is included). Since this can conceivably be going on in parallel in multiple threads, we really don't ever want to be sharing whatever object contains the head of the chain of tracebacks since it mutates at every frame bubble-up. I guess our next best option would be Glyph's suggested object to represent a caught exception, which could indeed be named "catch" per Greg's suggestion. The next-best option would be to clone the exception object whenever it is raised, but that seems wasteful in the normal case. -- --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
