Michael Chermside wrote: > It doesn't necessarily imply that > the traceback be materialized immediately upon exception creation > (which is undesirable because we want exceptions lightweight enough > to use for things like for loop control!)... but it might mean that > pieces of the stack frame need hang around as long as the exception > itself does.
With the current implementation, "materialising the traceback" and "keeping parts of the stack frame hanging around" are pretty much the same thing, since the traceback is mostly just a linked list of frames encountered while unwinding the stack looking for a handler. So if there's a possibility you might want a traceback at all at any point, it's hard to see how the process could be made any more lightweight. However, I'm wondering whether it might be worth distinguishing two different kinds of exceptions: "flow control" exceptions which are used something like a non-local goto, and full- blown exceptions. Flow control exceptions typically don't need most of the exception machinery -- they don't carry data of their own, so you don't need to instantiate a class every time, and you're not usually interested in a traceback. So maybe there should be a different form of raise statement for these that doesn't bother making provision for them. A problem is that if a flow control exception *doesn't* get caught by something that's expecting it, you probably do want a traceback in order to debug the problem. Maybe try-statements could maintain a stack of handlers, so the raise-control-flow-exception statement could quickly tell whether there is a handler, and if not, raise an ordinary exception with a traceback. Or maybe there should be a different mechanism altogether for non-local gotos. I'd like to see some kind of "longjmp" object that could be invoked to cause a jump back to a specific place. That would help alleviate the problem that exceptions used for control flow can get caught by the wrong handler. Sometimes you really want something that's targeted to a specific handler, not just the next enclosing one of some type. -- Greg _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
