On Thu, Feb 25, 2021 at 10:23 PM Glenn Linderman <v+python@g.nevcal.com> wrote:
So then why do you need except* at all? Only to catch unwrapped ExceptionGroup before it gets wrapped?
So why not write except ExceptionGroup, and let it catch unwrapped ExceptionGroup?
That "CUTE BIT" could be done only when hitting an except chain that doesn't include an except ExceptionGroup.
Nope, I didn't read the PEP, and don't understand the motivation, but the discussion sure sounded confusing. This is starting to sound almost reasonable.
I'm not sure what to make of the complaint that not reading the motivation makes the motivation confusing :-). But very briefly: the core reason we need ExceptionGroup is because in concurrent programs, multiple things can go wrong at the same time, so our error handling system needs to have some way to represent and cope with that. This means that in concurrent programs (e.g. anything using asyncio, trio, etc.), it's safest to assume that *any* exception could be wrapped in an ExceptionGroup and use except* for everything. The question is how to make error handling in those programs as ergonomic as Python exceptions are currently in non-concurrent programs, without creating too many issues for existing code. So in programs like this, you have to assume that 'except ExceptionGroup' catches *all* exceptions, or worse, a random/unpredictable subset. Saying that that would be good enough is like saying that bare 'except:' is good enough for regular non-concurrent Python (after all, you can always do an isinstance check inside the 'except' block and re-raise the ones you don't want, right?), and that 'except <some type>' is a pointless frivolity. I think most people would disagree with that :-). -n -- Nathaniel J. Smith -- https://vorpus.org