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 -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Message archived at https://email@example.com/message/445RAHP7XXLQFFGFKCXITPQPGAB55MDY/
Code of Conduct: http://python.org/psf/codeofconduct/