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.
As an alternative or addition to #5, it is possible to use Python's
try-exceptnatively:Note: See original comment in trio/#611 for further context and details not related to the
exceptAPI 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 viaCls[ExcA, ExcB], which should be common knowledge due totyping.Cons:
There are no native "subhandlers". Handling a
MultiError[A, B]just provides that kind of object; separating the handling of itsAandBcomponents must be done manually. Handling sub-exceptions may-or-may-not be part of theMultiErroritself, but requires nesting inside theexceptclass.The implementation is more complicated in that a metaclass is required: A clause
except A:usesissubclass(type(exception), A), which requires implementingtype(A).__subclasscheck__. Outwards simplicity is traded for inner complexity.