Then we should get some more opinions on this. I think it's the best idea so far for kindness towards code using `except Exception:`. I even think that the names I came up with are reasonable. The pseudo-code needs work: when instantiating ExceptionGroup, all errors should inherit from Exception, and I can't decide which base class for ExceptionGroup should come first: Exception or BaseExceptionGroup. I'm currently leaning slightly towards putting BaseExceptionGroup first. This is my current attempt:
```
class BaseExceptionGroup(BaseException):
    def __new__(cls, msg, errors):
        if cls is BaseExceptionGroup and all(isinstance(e, Exception) for e in errors):
            cls = ExceptionGroup
        else:
            assert all(isinstance(e, Exception) for e in errors)
        return super().__new__(cls, msg, errors)
    def __init__(self, msg, errors):
        self.msg = msg
        self.errors = errors
class ExceptionGroup(BaseExceptionGroup, Exception):
    pass
```

OT: Is ExceptionGroup *really* immutable in the current implementation? As long as the 'errors' field is a list, I think one could mutate the list directly. Which brings me to the question, do you have a branch that matches the PEP yet?

--Guido

On Thu, Feb 25, 2021 at 3:26 PM Irit Katriel <iritkatriel@googlemail.com> wrote:

We don't call it out but we talked about this at the sprint.  I think the reason we didn't come up with this solution then is that at the time ExceptionGroups in our plans were not immutable, so this would not have been possible (you don't know at construction time what it is going to contain).


On Thu, Feb 25, 2021 at 10:08 PM Guido van Rossum <guido@python.org> wrote:
So is "fail-fast if you forget to handle an ExceptionGroup" really a feature? (Do we call this out in the PEP?)

We may believe that "except Exception" is an abuse, but it is too common to dismiss out of hand. I think if some app has e.g. a main loop where they repeatedly do something that may fail in many ways (e.g. handle a web request), catch all errors and then just log the error and continue from the top, it's a better experience if it logs "ExceptionGroup: <message> [<list of subexceptions>]" than if it crashes.

There's also code that catches Exception, logs the error and some relevant data, and then re-raises it. The logged error may go to a more specialized destination than the generic traceback, and the log message may contain additional data that's only available in that stack frame.

So I think there are enough serious use cases that we should do what's best for those use cases, and not try to lecture users about abuse of the idiom.

I don't know what we would have done if we were building Python from scratch. Possibly we would not have BaseException at all, and the whole mess would go away. (But there are some good reasons why we introduced BaseException, so I don't know that that would really be a better overall experience.)

--Guido




--
--Guido van Rossum (python.org/~guido)