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.