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 <iritkatr...@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 <gu...@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)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZAEF52BHSTDPD5GF2O7YDYL6OSTOEJS2/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to