Hi Irit,
makes sense. So, in case of a *mixed-type ExceptionGroup,* SystemExit
wins and forces the program to exit.
Could you add your reasoning to the PEP?
This would help future readers and illustrates the chain of thoughts. It
might be obvious to you but from the outside it is really a long
journey. I actually liked your wording below and the explicitly writing
down the consequence I mentioned makes it very clear why this
complication exists.
Best,
Sven
On 03.03.21 21:13, Irit Katriel wrote:
Hi Sven,
This is all about the popularity of "except Exception".
Look at the hierarchy of builtin exceptions:
https://docs.python.org/3/library/exceptions.html#exception-hierarchy
<https://docs.python.org/3/library/exceptions.html#exception-hierarchy>
Most exceptions are subclasses of Exception. There are a few which are
not, because they typically mean "this process should exit" so you
should not usually handle them in your code. People use "except
Exception" as a way to "catch almost everything, but not the critical
stuff like SystemExit".
If we make ExceptionGroup be a BaseException, then "except Exception"
doesn't catch it. So we make it a subclass of Exception. But then we
can't make it wrap things like SystemExit, which people expect will
not be caught by "except Exception". So we add BaseExceptionGroup,
which is a subclass of BaseException and therefore is not caught by
"except Exception", so it can wrap SystemExit.
Why is the choice automated? Because it can be. You look at what
you're wrapping. If it's all subclasses of Exception, then it can be
ExceptionGroup. If there are BaseExceptions, then it needs to be
BaseExceptionGroup. There is no reason to ever do anything else.
I hope that makes sense.
On Wed, Mar 3, 2021 at 7:32 PM Sven R. Kunze <srku...@mail.de
<mailto:srku...@mail.de>> wrote:
Hey Irit,
find my 3 answers below:
On 03.03.21 13:17, Irit Katriel wrote:
> Hi Sven,
>
> I like your formatting suggestion, thanks. I will do something
like that.
You're welcome.
>
> I'm not sure I understand your question. ExceptionGroup is a
subclass
> of Exception (which is a subclass of BaseException). So
ExceptionGroup
> is caught by "except Exception" or "except BaseException".
1) So I understand "try-except BaseException" (cf.
concurrent.futures)
will work without fixes (i.e. produce the same results).
> BaseExceptionGroup is a subclass only of BaseException so it is
caught
> by "except BaseException" but not "except Exception". And
> ExceptionGroup is allowed to wrap only Exceptions while
BaseException
> can wrap Exceptions and and BaseExceptions. Makes sense?
2) Can you add motivating examples for "BaseExceptionGroup vs
ExceptionGroup" in the PEP? Right now, I only see what the
consequences
are but not why it was done this way.
3) Can you explain (and show the reasoning behind) this automatic
choice
in the PEP? Sounds a bit like hidden magic to me.
Referring to: "The difference between them is that ExceptionGroup can
only wrap Exception subclasses while BaseExceptionGroup can wrap any
BaseException subclass. A factory method that inspects the nested
exceptions and selects between ExceptionGroup and BaseExceptionGroup
makes the choice automatic."
Best
Sven
PS:
the reason why I was a bit puzzled by the
BaseExceptionGroup/ExceptionGroup issue is that:
- if it doesn't matter (so we do it automatically, because we do not
want to bother anybody), why do we need ExceptionGroup at all,
BaseExceptionGroup seems more flexible?
- if it does matter, why is the choice automatic and what if it
was the
wrong choice?
_______________________________________________
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/NYBCJCQWEH3T4VMURSAP7S6AZKSFN2C7/
Code of Conduct: http://python.org/psf/codeofconduct/
