A common example I see from the GitHub search is a catch all exception on some third party API. If the user wants to catch all exceptions from calling a third party API why would they want to let an ExceptionGroup go unhandled in the future? Once ExceptionGroups are introduced then libraries will surely implement them where appropriate and users would want to continue having their board exception handling working, would they not?
See my response to Ethan -- I think libraries should think twice before raising ExceptionGroup.
Note that ExceptionGroup is a subclass of BaseException, so if you're catching the latter you don't have to do anything special.
OTOH we might reconsider deriving ExceptionGroup from BaseException -- maybe it's better to inherit from Exception? I don't think the PEP currently has a clear reason why it must derive from BaseException. I believe it has to do with the possibility that ExceptionGroup might wrap a BaseException instance (e.g. KeyboardInterrupt or SystemExit). But I believe that this was more important in an earlier revision of the design. Note that there is a section labeled "Should MultiError inherit from BaseException, or from Exception? (Or something else?)" in Trio's MultiError v2 issue (
https://github.com/python-trio/trio/issues/611). I think the key argument here is "However, if
MultiError is an
Exception, then it can only contain
Exception subclasses, because otherwise a
MultiError(KeyboardInterrupt) could get caught by an
except Exception handler, which would be bad." But those notes are from back in 2018, not from the 2020 core dev sprint when we got much closer to the current design. So I'm not sure the reasoning still applies. (Yury? Can you help us out here?)
I don't actually know if the code I wrote in the first email is correct though, would it catch all standard Exception / ExceptionGroups across Python 3.x if this PEP was implemented in the future? And would it be best practice for this pattern? If so it seems it would require many users to rewrite their code as it adds boilerplate and nuance for a pattern that is a relatively simple and very commonly used right now.
I guess summarized my commentary is please don't dismiss this pattern out of hand, which this PEP currently disrupts, it is used widely in Python right now and has many valid use cases. I don't have anything further to add so I won't continue this discussion and I assume anything further you have to add to be considered and more informed than my own opinion.
I expect that if you want to do a good job of emulating `except *ValueError` in Python versions that don't have ExceptionGroup you're going to have to write more code. It's relatively straightforward if you just want to ignore or log the errors collectively, but it'll be more complex if you want to handle each suberror separately, because the PEP-654-aware code will have to iterate over the errors, recursing into ExceptionGroup instances. (Irit, maybe the PEP could use a worked-out example of how to do the latter -- even with `except *` available it seems non-trivial.)
Thanks Damian for getting us to think more about 'except Exception:'