We would like to request feedback on PEP 654 -- Exception Groups and except*.
It proposes language extensions that allow programs to raise and handle multiple unrelated
exceptions simultaneously, motivated by the needs of asyncio and other concurrency libraries,
but with other use cases as well.
* A new standard exception type,
ExceptionGroup, to represent multiple exceptions with
* Updates to the traceback printing code to display (possibly nested) ExceptionGroups.
* A new syntax except* for handling ExceptionGroups.
A reference implementation (unreviewed) can be found at:
Have you considered alternative syntax to the "except*"?
I feel that expect* is too easy to confuse with plain except.
As others have said needing to change all except Exception:
handlers would be a breaking change for code that I maintain.
I think its accepted that that idiom should continue to be as
reliable as it currently is. Can you confirm that I have understood
the conversation on this point?
I have been thinking about why I would be getting an ExceptionGroup
with, for example, a number of OSError for a handler to deal with.
Would it not be a difficult piece of code to write without the context of
What I'm think is that the lower level pieces would be catching the OSError
closer to the source of the problem and raising a App/Lib specific exception
that provides the context. For example AppFailedToSaveConfigError and
AppFailedToSaveDataError as oppose to a two permission OSError's.
With context I can imagine that handling the ExceptionGroup would be
a lot easier for the App designer.
If that the pattern that emerges then is the complexity of nested
ExceptionGroups going to only rarely used?