On Thu, Feb 25, 2021 at 5:19 AM Guido van Rossum <guido@python.org> wrote:
[Subthread: handling individual errors]

> Rather than iterator, I think we should add a visitor that calls a function for each leaf exception,

I agree that we shouldn't add an `__iter__` method. But what if we added a separate method that returns an iterator? Then you could write
```
for e in eg.something():
    print("caught", e)
```
This looks cleaner to me than having to write
```
def handler(e):
    print("caught", e)
eg.something(handler)
```
(Does my bias against callback functions shine through? :-)


I hear you. I suggested a visitor to make it a bit awkward to use because I'm not sure why people should iterate over individual exceptions in an ExceptionGroup, and I think that by providing an iteration utility we are implying that this is what you should do.
So let me be more direct instead of proposing passive-aggressive APIs. 

Can we take a step back and talk about how we think people would want to handle ExceptionGroups?

In the rejected ideas section we discuss this a bit, with a reference to Yury's writeup: https://github.com/python/exceptiongroups/issues/3#issuecomment-716203284

TL;DR:  when you get a group of exceptions from asyncio or the like, you may want to query it for exception types is contains (with subgroup()), you may want to format it into a log (with traceback.* methods), but you are unlikely to care whether there are 1, 2 or 300 ValueErrors. Your program will probably do the same thing regardless. If you allowed your ValueError get collected into an ExceptionGroup you already lost the context in which it happened to it's unlikely that you can make a targeted recovery which is relevant to this particular exception.

So, what is the use case for iterating over single exceptions?