Improving handler ergonomics for ExceptionGroup("", [HTTPException(404)])

[Zac-HD]

Because the exception handler checks isinstance(exc, HTTPException), any endpoint code nested inside a TaskGroup which wishes to raise an HTTPException faces a trilemma:

1. Register an additional exception handler, for ExceptionGroup, which will either look up and invoke the appropriate handler for the leaf exception (reimplementing part of the exception handler), or re-raise if there is more than one leaf.
2. Wrap every endpoint in a decorator (or middleware) which "unwraps" single-leaf ExceptionGroups before the exception handler sees them.
3. Arrange that the endpoint should raise HTTPException outside the TaskGroup (and to cancel work in flight, etc).

Unfortunately, none of these options are particularly ergonomic - and the first two require very unusual care if you don't want to drop the traceback sections attached an ExceptionGroup.

I therefore propose that Starlette unwrap single-leaf ExceptionGroups inside the handler function, avoiding this trilemma. That does raise a further question though: what should we do if there is a handler registered for (Base)ExceptionGroup?

• Always use the registered handler. Simple principle, and we can document a "defer-for-single-leaf" recipe for users who want that behavior.
• Use the unwrap logic if there's a single leaf, and fallback to the registered group handler if there are multiple leaves
  • and also fall back to the group handler if the leaf is not otherwise handled.

I prefer the first option, especially if we can provide a helper function to make user-implementation of the latter easy. I'd be happy to implement this if maintainers would like a PR 🙂