[Python-3000] The future of exceptions

[Greg Ewing]

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