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!
Irit