Proposal: native exception handling API #20
Description
As an alternative or addition to #5, it is possible to use Python's try-except natively:
try:
async with something:
something.raise_concurrent()
except MultiError[A]:
print("Handled concurrent A")
except MultiError[A, B] as err:
print("Handled concurrent A and B")
except (MultiError[B], MultiError[C]) as err:
print("Handled concurrent B or C:", err)
except A:
print("Handled non-concurrent A")Note: See original comment in trio/#611 for further context and details not related to the except API itself. The approach has been implemented and tested in the usim simulator.
Pros:
The primary advantage here is that exception group handling follows the same rules as regular exception handling. The sequence of handlers, how handlers are executed, and the scope in which they are executed, are the same.
Users do not have to import additional tools for catching exceptions (splitting etc. is not part of this proposal). Everything can be encapsulated in the MultiError/ExceptionGroup. The only visible "trick" is templating via Cls[ExcA, ExcB], which should be common knowledge due to typing.
Cons:
There are no native "subhandlers". Handling a MultiError[A, B] just provides that kind of object; separating the handling of its A and B components must be done manually. Handling sub-exceptions may-or-may-not be part of the MultiError itself, but requires nesting inside the except class.
The implementation is more complicated in that a metaclass is required: A clause except A: uses issubclass(type(exception), A), which requires implementing type(A).__subclasscheck__. Outwards simplicity is traded for inner complexity.