Hi Ethan,

See Irit's response to my about why ExceptionGroup doesn't subclass Exception -- I think this is still a little bit of an open issue.

Another response (which I also read somewhere in one of Irit's messages) is that a library API shouldn't go from raising subclasses of Exception only to raising ExceptionGroups. That would be a backwards incompatible change to an API.


On Tue, Feb 23, 2021 at 8:52 PM Ethan Furman <ethan@stoneleaf.us> wrote:
On 2/23/21 7:56 PM, Guido van Rossum wrote:
> On Tue, Feb 23, 2021 at 7:37 PM Ethan Furman wrote:

>> It sounds like the long-term goal is to move away from `except` and
>> replace it with `except *` -- is that correct?
> I don't think so -- if we expected that to happen the extra '*' in the
> syntax would be a nuisance. The premise of the PEP is rather that
> raising and catching multiple exceptions at once is always going
> to be an esoteric hobby. The most common case by far would be in async
> frameworks, but we don't expect 'async def' to eventually become the
> standard function definition either (nor 'await f()' the standard call :-).
> And even in an async framework, I don't expect that every async function
> would be "upgraded" to raise ExceptionGroup -- only specific APIs like
> gather() or create_connection(). (Even for those, backwards compatibility
> concerns will probably mean that we'll have to introduce *new* APIs that
> can raise ExceptionGroup.) The PEP lists a handful of other use cases,
> none of which seem to suggest to me that this is going to be a common thing.

I can see the value in `except *` for concurrent code; my concern is how it will operate with the standard `try/except` framework.  With the new non-Exception-derived ExceptionGroup class, existing try-excepts that catch Exception will fail for every ExceptionGroup that leaks through; the fix for that is a doubly-nested try-except/try-except* -- what do we get for that code churn?  What is the advantage in not deriving from Exception?  If I recall correctly, we have only three exception types that derive directly from BaseException: Exception, SystemExit, and KeyboardInterrupt -- with SystemExit and KeyboardInterrupt both being concerned with making sure an application can quit.

Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/445RAHP7XXLQFFGFKCXITPQPGAB55MDY/
Code of Conduct: http://python.org/psf/codeofconduct/

--Guido van Rossum (python.org/~guido)
Pronouns: he/him (why is my pronoun here?)