Against mixing `ExceptionGroup` and naked exceptions

[Zac-HD]

Contra the rejected idea Not matching naked exceptions in except*, I think it's subtly dangerous to have except* FooError to match both FooError and ExceptionGroup[FooError]. In short, the current proposal treats unhandled operation errors as control flow exceptions, and IMO "the burden of having to explicitly handle both" is indeed a semantic benefit.

This is based on my - and others, though I don't have a written reference to hand - experience with Trio: when an error may or may not be an ExceptionGroup, users will tend to only handle the more common case. The common/naive misuse of "bare except:" is a good example here; IMO disallowing bare-except would be better than the status quo (though except: -> except Exception: would be better still).

I therefore propose that either:

• except* can only catch ExceptionGroup and subclasses thereof, never naked exceptions, (my preferred option)
• or we require that ExceptionGroup be named in the except* block:

try:
   ...
except* ExceptionGroup[FooError] as eg:
   ...
except* (TypeError, ExceptionGroup[TypeError]) as eg:
   ...

---

Taking the same principles too far, we would get:

try:
   ...
except FooError as err:
   ...
except ExceptionGroup[FooError] as eg:
   ...
except (TypeError, ExceptionGroup[TypeError]) as eg:
   ...

This would obviously require the except statement to grow magical awareness of ExceptionGroup, which I don't particularly like, but the only (substantial!) advantage of the except* statement is dedicated syntax for running all matching clauses. As a clean(ish) way to avoid new syntax I think this probably deserves a place under rejected ideas.

[gvanrossum]

Actually, one reason for the except * syntax is that we can assure that the type of the variable following as is always an ExceptionGroup instance. That is, while except *TypeError as e indeed catches bare exceptions, e is always ExceptionGroup[TypeError].

Also, IIRC we disallow bare except *: (Alas, doing anything about bare except: is out of scope, and not likely given backwards compatibility requirements. Maybe something for Python 4.0. :-)

[1st1]

Actually, one reason for the except * syntax is that we can assure that the type of the variable following as is always an ExceptionGroup instance. That is, while except *TypeError as e indeed catches bare exceptions, e is always ExceptionGroup[TypeError].

FWIW that was the idea from the start of except_star.md

https://github.com/python/exceptiongroups/blob/master/except_star.md#naked-exceptions

[1st1]

This is based on my - and others, though I don't have a written reference to hand - experience with Trio: when an error may or may not be an ExceptionGroup, users will tend to only handle the more common case.

I think this is actually the argument for except* catching both naked errors and groups. I suspect that the main reason that Trio users were handling just one case forgetting about the other one is because handling MultiErrors is very cumbersome and looks nothing alike to a regular except SomeError clause. Another reason is a design mistake of the current Trio nursery/multierror: not wrapping an exception propagating out of a nursery into a MultiError if there are no other exceptions. That makes it very hard to write correct code: except ValueError might work until you add another task to the nursery that also can raise a ValueError.

I'm also +1 for disallowing bare except*:.

[Zac-HD]

The reason I want to avoid except* catching naked exceptions is precisely so that the language will discourage Trio's design mistake: if "except* only catches ExceptionGroup", library designers have a strong incentive to raise naked exceptions xor ExceptionGroup.

---

Re: disallowing bare except*: - I proposed that in #16 (comment) 😁

[1st1]

The reason I want to avoid except* catching naked exceptions is precisely so that the language will discourage Trio's design mistake: if "except* only catches ExceptionGroup", library designers have a strong incentive to raise naked exceptions xor ExceptionGroup.

The current proposal makes everything work by design: no matter how the error was raised, you can catch it. If your code is asynchronous and can deal with multiple errors you can just use the except *ValueError and not worry about some ValueErrors slipping by. I like that aspect of it and I think it's a good DX for end users.

The modification you propose would make library designers think hard in every case they raise an exception; a simple misjudgment about one exception would be impossible to fix in the next release because users could already start catching that very exception with either except or except*. As a maintainer of a few async libraries I wouldn't enjoy that. :/

Re: disallowing bare except*: - I proposed that in #16 (comment) 😁

Very good catch!

[Zac-HD]

a simple misjudgment about one exception would be impossible to fix in the next release because users could already start catching that very exception with either except or except*.

This is an excellent point that I had not considered - thanks!