Hi Greg, 

If all you want is to catch an exception group and process it, then except* does look like overkill.

It gets more interesting if you want to handle only some of the exceptions and reraise the rest (without adding the current frame to the traceback), or when the exception handler raises/reraises exceptions (with 'raise e' or bare 'raise').

We can look to Trio to see what exception handling would be like if we add ExceptionGroup without except*. 
Trio's exception group is called MultiError, and this part of the tutorial explains how they can be handled:
https://trio.readthedocs.io/en/stable/reference-core.html#trio.MultiError

So asyncio (or some new module in the stdlib) would probably end up exposing something along the lines of MultiError.catch, a context manager where you register the exception handler as a callback and the unhandled exceptions are automatically reraised.
You can see the trio code for that here: https://github.com/python-trio/trio/blob/master/trio/_core/_multierror.py#L129
The trick it does to reset __context__ in the finally block won't work for the __traceback__ (I tried). So it always adds the current frame (if it doesn't return before line 145).

Also, it doesn't seem to support raising exceptions from the handler: https://github.com/python-trio/trio/blob/6754c74eacfad9cc5c92d5c24727a2f3b620624e/trio/_core/_multierror.py#L79

So yes, we can catch exception groups and handle them like normal exceptions, but I don't see a clean way to catch parts of them selectively or to raise exceptions from exception handling code.

Irit

 
On Sat, Mar 27, 2021 at 10:57 PM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
While we're talking about compelling use cases, does anyone have an
actual, concrete use case for the proposed "except *" feature that's
strong enough to justify new syntax?

I'm fine with having ExceptionGroup as a built-in type. I'm not fine
with adding new syntax that will apparently be used only in rare
circumstances.

Can code that's aware of the possibility of getting an ExceptionGroup
not simply catch it as a normal exception and then pick it apart? Do
we really need a whole new piece of machinery for this?

--
Greg

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EIW6JGXRWKEEIY72CGZ7BMKU3LHJIZQK/
Code of Conduct: http://python.org/psf/codeofconduct/