Catching exceptions like this is an extremely common pattern in the real
world, e.g. this pattern has over 5 million GitHub matches:
How common it is aside there are also many valid use cases for this
pattern, e.g. logging a final unhandled exception of a script, catching
exceptions inside an orchestration framework, exploring code where the list
of exceptions is unknown, etc.
A description from the PEP on how to handle this kind of pattern,
especially for code that must support multiple versions of Python, would be
On Tue, Feb 23, 2021 at 2:35 PM Irit Katriel
On Tue, Feb 23, 2021 at 3:49 PM Damian Shaw
Firstly, if I have a library which supports multiple versions of Python and I need to catch all standard exceptions, what is considered the best practise after this PEP is introduced?
Currently I might have code like this right now: try: ... # Code except Exception as e: ... # Logic to handle exception
Catching all exceptions in this way is not a common pattern. Typically you have an idea what kind of exceptions you expect to get from an operation, and which of those exceptions you are interested in handling. Most of your try/except blocks will be targeted, like handling KeyError from d[k], an operation that will never raise an ExceptionGroup.
ExceptionGroups will only be raised by specific APIs which will advertise themselves as such. We don't expect that there will be a need for blanket migrations of "except T" to "except (T, ExceptionGroup)" to "except *T".