idea: add an asynchronous exception class

[Paul Rubin]

I'd like to suggest adding a builtin abstract class to Python called
AsynchronousExc eption, which would be a subclass of Exception. The
only asynchronous exception I can think of right now is
KeyboardInterru pt, so KeyboardInterru pt would become a subclass of
AsynchronousExc eption 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 AsynchronousExc eption.

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 AsynchronousExc eption. 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]

Re: idea: add an asynchronous exception class

On Fri, 03 Mar 2006 22:31:49 -0800, Paul Rubin wrote:
[color=blue]
> I'd like to suggest adding a builtin abstract class to Python called
> AsynchronousExc eption, which would be a subclass of Exception.[/color]

[snip rationale]

+1 on this.



--
Steven.

[Fredrik Lundh]

Re: add an asynchronous exception class

Paul Rubin wrote:
[color=blue]
> I'd like to suggest adding a builtin abstract class to Python called
> AsynchronousExc eption, which would be a subclass of Exception. The
> only asynchronous exception I can think of right now is
> KeyboardInterru pt, so KeyboardInterru pt would become a subclass of
> AsynchronousExc eption instead of being a direct subclass of Exception.[/color]

PEP 348 addresses this by moving special exceptions out of the
Exception hierarchy:

http://www.python.org/peps/pep-0348.html

</F>

[Paul Rubin]

Re: add an asynchronous exception class

"Fredrik Lundh" <fredrik@python ware.com> writes:[color=blue]
> PEP 348 addresses this by moving special exceptions out of the
> Exception hierarchy:
>
> http://www.python.org/peps/pep-0348.html[/color]

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]

Re: add an asynchronous exception class

On Sat, 04 Mar 2006 08:41:48 +0100, Fredrik Lundh wrote:
[color=blue]
> Paul Rubin wrote:
>[color=green]
>> I'd like to suggest adding a builtin abstract class to Python called
>> AsynchronousExc eption, which would be a subclass of Exception. The
>> only asynchronous exception I can think of right now is
>> KeyboardInterru pt, so KeyboardInterru pt would become a subclass of
>> AsynchronousExc eption instead of being a direct subclass of Exception.[/color]
>
> PEP 348 addresses this by moving special exceptions out of the
> Exception hierarchy:
>
> http://www.python.org/peps/pep-0348.html[/color]

The PEP has been summarily rejected, perhaps because it was too broad in
the changes it suggested.



--
Steven.

[Robert Kern]

Re: add an asynchronous exception class

Paul Rubin wrote:[color=blue]
> "Fredrik Lundh" <fredrik@python ware.com> writes:
>[color=green]
>>PEP 348 addresses this by moving special exceptions out of the
>>Exception hierarchy:
>>
>> http://www.python.org/peps/pep-0348.html[/color]
>
> 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.[/color]

The relevant part of PEP 348 survived as PEP 352.

http://www.python.org/peps/pep-0352.html

--
Robert Kern
robert.kern@gma il.com

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Christian Stapfer]

Re: add an asynchronous exception class

"Paul Rubin" <http://phr.cx@NOSPAM.i nvalid> wrote in message
news:7xu0aemyil .fsf@ruckus.bro uhaha.com...[color=blue]
> "Fredrik Lundh" <fredrik@python ware.com> writes:[color=green]
>> PEP 348 addresses this by moving special exceptions out of the
>> Exception hierarchy:
>>
>> http://www.python.org/peps/pep-0348.html[/color]
>
> 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/pyt...st/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)?[/color]

I guess it means the following:

"Terminatin g 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]

Re: add an asynchronous exception class

"Christian Stapfer" <nil@dev.nul> writes:[color=blue]
> I guess it means the following:
>
> "Terminatin g exceptions" are exceptions that
> terminate the *thrower* of the exception.[/color]

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]

Re: add an asynchronous exception class

"Paul Rubin" <http://phr.cx@NOSPAM.i nvalid> wrote in message
news:7xwtf9kida .fsf@ruckus.bro uhaha.com...[color=blue]
> "Christian Stapfer" <nil@dev.nul> writes:[color=green]
>> I guess it means the following:
>>
>> "Terminatin g exceptions" are exceptions that
>> terminate the *thrower* of the exception.[/color]
>
> Are you sure?[/color]

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