> In fact, if you're happy with RuntimeError here, making
> ExceptionGroup inherit from Exception (instead of
> BaseException) would do just as well -- after all RuntimeError
> is pretty arbitrary
Agreed, and I think it should inherit from Exception.
> (in fact, it's wrong, because the problem is a static bug in the
> code, not something that went wrong at run time).
Something went wrong deep inside an individual task. The only clear static bug
is that the async library changed how it reported that, and my except clause
hasn't done the make-work to keep in step.
> Let's see how this compares to the alternatives. First let's define
> three key examples.
> Example 1:
> try:
> raise ExceptionGroup(ValueError)
> except Exception:
> Example 2:
> try:
> raise ExceptionGroup(ValueError)
> except ValueError:
Example 2(a) :
try:
raise ExceptionGroup(ValueError,OtherError)
except ValueError:
> Example 3:
> try:
> raise ExceptionGroup(asyncio.CancelledError)
> except Exception:
I would prefer that the except clause be executed in all of the examples, but I
admit that 2a is a problem, because it could end up silently losing OtherError.
And I admit getting example 2 to do the right thing if 2a doesn't might be too
much of a contortion.
For example 3, I may be missing a subtle point, but I feel that by the time you
get to code which doesn't expect asyncio.CancelledError, then you have already
cancelled as far as you should. Cancelling may want to bubble up through
several other tasks, but it shouldn't kill the whole server, just because the
trampoline got sloppy.
-jJ
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/RHL3E2IBCIW2SP5L5W3BHWIWB4DV6U55/
Code of Conduct: http://python.org/psf/codeofconduct/
