Thank you for your careful reading and encouragement.
The `ExceptionGroup` class is final, i.e., it cannot be subclassed.
What's the rationale for this?
ExceptionGroup.subgroup()/split() need to create new instances, and subclassing would make that complicated if we want the split results to have the same type.
It is possible to catch the ExceptionGroup type with except, but not with except* because the latter is ambiguous
What about `except *(TypeError, ExceptionGroup):`?
Good question. We should block that as well.
Motivation: Errors in wrapper code
This use case sticks out a bit: it's the only one where ExceptionGroup doesn't represent joining equivalent tasks. Consider code similar to bpo-40857:
try: with TemporaryDirectory() as tempdir: os.rmdir(tempdir) n = 1 / 0 except ArithmeticError: # that error can be safely ignored! pass
Instead of a FileNotFoundError with ArithmeticError for context you'd now get an ExceptionGroup. Neither is handled by `except ArithmeticError`. Where is the win?
I agree, if TemporaryDirectory() were ever to adopt ExceptionGroups then it will probably be through a new API (like an opt-in parameter) to avoid breaking current code. Users of such a TemporaryDirectory would need to wrap the calls with try-except* (see the example in my previous reply to Steve).
Motivation: Multiple failures when retrying an operation
This is somewhat similar to the TemporaryDirectory, except there's no `with` block that feels like it should be "transparent" w.r.t. user errors. If I currently have:
try: create_connection(*addresses) except (Timeout, NetworkNotConnected): # that's OK, let's try later pass
what should happen after Python 3.10? Apart from adding a new function, I can see two possible changes:
- create_connection() starts always raising ExceptionGroup on error,
breaking backwards compatibility in the error case
- create_connection() starts only raising ExceptionGroup only for 2+
errors, breaking backwards compatibility in the 2+ errors case
Both look like heisenbug magnets. IMO, the second one is worse; "code which is now *potentially* raising ExceptionGroup" (as mentioned in the Backwards Compatibility section; emphasis mine) should be discouraged.
Arguably, this here is a problem with the create_connection function: the PEP adds a better way how it could have been designed, and that is virtuous. Still, having it in Motivation might be misleading.
I agree. Raising ExceptionGroups is an API breaking change, for any library. No function should just start raising ExceptionGroups.
long term plan to replace `except` by `catch`
Whoa! Is that a real plan?
In the rejected ideas section, anything goes!