> 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/