We really don’t want users pushing non-exceptions into the list, nor do we want e.g. KeyboardInterrupt to be added to a (non-Base-) ExceptionGroup.
There’s a pattern for what you propose using the split() method and a lambda, or you can keep the exceptions in a list and re-wrap them at the end.
On Sat, Feb 27, 2021 at 20:41 Cameron Simpson <
cs@cskk.id.au> wrote:
On 26Feb2021 02:44, Irit Katriel <iritkatriel@googlemail.com> wrote:
>On Fri, Feb 26, 2021 at 2:00 AM Guido van Rossum <guido@python.org> wrote:
>> 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.
>
>It's not, but we were going to make it an immutable tuple.
Could you say why? Other than wanting to discourage mutation happy code
getting out there?
The reason I ask is that the scenario which comes to my mind is
something like:
except *OSError as e:
AIUI "e" is an ExceptionGroup containing only OSErrors. So, one common
thing in my own code is this:
try:
do something with a file
except OSError as e:
if e.errno == ENOENT:
# file is missing, but that is ok
# because we treat it like an empty file
elif ... some other ok situation ...
else:
raise
My natural inclination with an ExceptionGroup would be to winnow the
OSErrors I'm handed, and push the _unhandled_ errors back into the
original ExceptionGroup. That way, after the various except* clauses, a
nonempty ExceptionGroup would remain with the unhandled errors, and it
might perhaps be reraised then.
Cheers,
Cameron Simpson <cs@cskk.id.au>
--
--Guido (mobile)