![](https://secure.gravatar.com/avatar/d8acc82e7320875de644e87b27cc44aa.jpg?s=120&d=mm&r=g)
Hi Irit, 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? 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. Thanks, Damian On Tue, Feb 23, 2021 at 4:41 PM Irit Katriel <iritkatriel@googlemail.com> wrote:
Hi Damian,
While I agree that there are a handful of use cases for catching all Exceptions, if you look at some of the 5 million hits you found in github, the vast majority are not such cases. They are mostly try/except blocks that wrap a particular operation (a dict access, a raw_input call, etc). You don't want to automatically translate "except Exception" to something that involves ExceptionGroups, because most of the time it is not needed -- the code in the body can't raise ExceptionGroups.
Your first email on this thread showed that you were able to quite quickly, just from what's already in the PEP, think of how to do what you need for your valid "except Exception" use case. My feeling is that people who need it will be able to do it quite easily. I'm more worried about people assuming that they need it when they don't.
Irit
On Tue, Feb 23, 2021 at 8:00 PM Damian Shaw <damian.peter.shaw@gmail.com> wrote:
Hi Irit,
Catching exceptions like this is an extremely common pattern in the real world, e.g. this pattern has over 5 million GitHub matches: https://github.com/search?l=&q=%22except+Exception%22+language%3APython&type=code
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 extremely helpful.
Damian