add an asynchronous exception class

Christian Stapfer nil at dev.nul
Sat Mar 4 18:00:24 CET 2006

"Paul Rubin" <> wrote in message 
news:7xu0aemyil.fsf at
> "Fredrik Lundh" <fredrik at> writes:
>> PEP 348 addresses this by moving special exceptions out of the
>> Exception hierarchy:
> I see that suggestion was rejected (it needed changing the semantics
> of "except:").  Also, PEP 348 was rejected and is a huge, complex
> reorganization of the whole exception system.  This is cited:
> but it talks about distinguishing terminating from non-terminating
> exceptions, whatever that means.  (Won't any uncaught exception like
> ValueError terminate the program)?

I guess it means the following:

"Terminating exceptions" are exceptions that
terminate the *thrower* of the exception.
"Non-terminating exceptions" are exceptions
that might allow the thrower to resume
(provided the catcher does *not* decide
to unwind the thrower's stack frame - and
possibly some other frames as well...).
So non-terminating exceptions allow the
thrower to offer the catcher a choice
between terminating the thrower or having
him try harder (until he possibly throws
yet another, but maybe this time terminating
exception that does not allow the catcher to
ask for resumption of the throwing code).

  So what's terminated (or not terminated)
here is not the program but merely the
code that throws an exception.
  VAX/VMS had such a non-terminating exception
handling mechanism, for example.


More information about the Python-list mailing list