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.
On 03.03.21 21:13, Irit Katriel wrote:
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 <email@example.com mailto:firstname.lastname@example.org> 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?