1. Having now read the PEP, I don't actually see a use case for
grouping BaseExceptions. Why would anyone catch KeyboardInterrupt or
SystemExit and wrap them in a BaseExceptionGroup anyway? It seems to
me that the right thing to do, even in async or parallel code, is to
just propogate the KeyboardInterrupt/SystemExit up to the main
program. Losing a ValueError that happened at the exact same time as
the user pressed Ctrl-C seems like it's not going to be a problem in
practice...
It is possible that your program wants to do something other than just terminate when it gets a KeyboardInterrupt. Otherwise why does the interpreter bother propagating the KeyboardInterrupt
rather than just terminate the program there and then?
And the ValueError you lost may be some other error type that involves cleanup.
If you do this:
try:
async.gather(...) # raises BaseExceptionGroup(
DoCleanup(), KeyboardInterrupt())
except *
DoCleanup:
do_cleanup() # log stuff, send notifications, close sockets, whatever
That will do the cleanup in addition to propagating a BaseExceptionGroup(KeyboardInterrupt())
Also, KeyboardInterrupt/SystemExit are not the only BaseExceptions.
2. Given the above, why even have a means of grouping BaseExceptions
at all? Why not just have ExceptionGroup that can only catch instances
of Exception?
Because the IGotInterrupted alternative involves wrapping a BaseException by an Exception, which is not something we should push people into doing (it's not that different from allowing ExceptionGroup to wrap BaseExceptions directly).
What's the harm/complication in offering a BaseExceptionGroup(BaseException) in addition to ExceptionGroup(BaseExceptionGroup, Exception)?
I think the only reason you're comfortable with having to select between the exceptions that were raised and discard some of them is because that's where we are today. The PEP lists several standard library and other APIs that discard errors because they need to pick one. That's what we're trying to fix.
Irit