idea: add an asynchronous exception class
Paul Rubin
AsynchronousException, which would be a subclass of Exception. The
only asynchronous exception I can think of right now is
KeyboardInterrupt, so KeyboardInterrupt would become a subclass of
AsynchronousException instead of being a direct subclass of Exception.
There's been talk of adding ways of raising asynchronous exceptions
across threads from user code, so those exceptions would also be
subclassed from AsynchronousException.
The reason for wanting this is the common idiom
try:
run_parrot_code() # might raise ParrotException
except ParrotException:
pass # or do some stuff
except IOError:
pass
except:
# run_parrot_code raised something unexpected
print 'unexpected exception'
raise
The catchall except: block captures not only unexpected exceptions
raised from the dynamic scope of the try: block, but also any
asynchronous exception that might be raised. It should have a way to
distinguish between those two cases, i.e. by checking whether the
caught exception is an instance of AsynchronousException. That's
better than checking for all known asynchronous exceptions explicitly
and then having the code break when a new such exception gets added.
Catchall "except" blocks are generally frowned on because of this
issue but they're used all over the place anyway.
The suggestion above is extremely simple to implement but there might
be better ways to solve the problem.
Steven D'Aprano
> I'd like to suggest adding a builtin abstract class to Python called
> AsynchronousException, which would be a subclass of Exception.
[snip rationale]
+1 on this.
--
Steven.
Fredrik Lundh
> I'd like to suggest adding a builtin abstract class to Python called
> AsynchronousException, which would be a subclass of Exception. The
> only asynchronous exception I can think of right now is
> KeyboardInterrupt, so KeyboardInterrupt would become a subclass of
> AsynchronousException instead of being a direct subclass of Exception.
PEP 348 addresses this by moving special exceptions out of the
Exception hierarchy:
http://www.python.org/peps/pep-0348.html
</F>
Paul Rubin
> PEP 348 addresses this by moving special exceptions out of the
> Exception hierarchy:
>
> http://www.python.org/peps/pep-0348.html
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:
http://mail.python.org/pipermail/python-dev/2005-August/055423.html
but it talks about distinguishing terminating from non-terminating
exceptions, whatever that means. (Won't any uncaught exception like
ValueError terminate the program)?
I realize now that exceptions arising from signals are also asynchronous
(http://docs.python.org/lib/module-signal.html). So that's another
place where we'd see user-defined asynchronous exceptions: signal
handlers should raise them instead of raising ordinary exceptions.
Steven D'Aprano
The PEP has been summarily rejected, perhaps because it was too broad in
the changes it suggested.
--
Steven.
Robert Kern
> "Fredrik Lundh" <fre...@pythonware.com> writes:
>
>>PEP 348 addresses this by moving special exceptions out of the
>>Exception hierarchy:
>>
>> http://www.python.org/peps/pep-0348.html
>
> 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.
The relevant part of PEP 348 survived as PEP 352.
http://www.python.org/peps/pep-0352.html
--
Robert Kern
rober...@gmail.com
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
Christian Stapfer
news:7xu0aem...@ruckus.brouhaha.com...
> "Fredrik Lundh" <fre...@pythonware.com> writes:
>> PEP 348 addresses this by moving special exceptions out of the
>> Exception hierarchy:
>>
>> http://www.python.org/peps/pep-0348.html
>
> 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:
>
> http://mail.python.org/pipermail/python-dev/2005-August/055423.html
>
> 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.
Regards,
Christian
Paul Rubin
> I guess it means the following:
>
> "Terminating exceptions" are exceptions that
> terminate the *thrower* of the exception.
Are you sure? I didn't read it that way. I'm not aware of there ever
having been a detailed proposal for resumable exceptions in Python,
though the gurus would know better than I do whether there's been one.
Christian Stapfer
> "Christian Stapfer" <n...@dev.nul> writes:
>> I guess it means the following:
>>
>> "Terminating exceptions" are exceptions that
>> terminate the *thrower* of the exception.
>
> Are you sure?
Am I sure? - Well no! As I wrote: this is
just my *guess*.
But if certain terms are not explained
upfront then, I assume, the writer must have
had some "well known" interpretation in mind.
These two alternatives, the abortion and
the resumption model of exception handling,
are certainly that: "well known". Hence
my guess...
Regards,
Christian