[Python-3000] The future of exceptions

[Marcin 'Qrczak' Kowalczyk]

Greg Ewing <greg.ewing at canterbury.ac.nz> writes:

> 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,

It's lazily instantiated today (see PyErr_NormalizeException).

> 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.

Any non-local exit should be hookable by active function calls between
the raising point and the catching point, especially by things like
try...finally.

> Sometimes you really want something that's targeted to a specific
> handler, not just the next enclosing one of some type.

Indeed, but this can still use an exception internally. My language
Kogut has a function for that ('?' is lambda, the whole thing is an
argument of 'WithExit'):

WithExit ?exit {
   some code
   which can at some point
   call the 'exit' function introduced above,
   even from another function,
   and the control flow will return to this WitExit call
};

I think it can be exposed as something used with 'with' in Python.
'WithExit' constructs a unique exception object and catches precisely
this object.

Implementing it with an exception makes the semantics of expression
evaluation more uniform: an expression either evaluates to a value,
or fails with an exception, and there is no other possibility which
would have to be accounted for in generic wrappers which call unknown
code (e.g. my bridge between two languages, or running a computation
by another thread).

There are other kinds of non-local exits, like exiting the program
or thread cancellation, which can be implemented with exceptions and
I think it's better than inventing a separate mechanism for each.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/