Just to add +1 for Paul's concerns. Even though ExceptionGroups "are not supposed" to not leak into caller code, don't mean they "won't". Making "except Exception" catch them would make this part a non issue, and the feature looks great otherwise. On Wed, 3 Mar 2021 at 13:44, Paul Moore <p.f.moore@gmail.com> wrote:
On Wed, 3 Mar 2021 at 14:59, Irit Katriel <iritkatriel@googlemail.com> wrote:
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).
That's a fair point.
What's the harm/complication in offering a BaseExceptionGroup(BaseException) in addition to ExceptionGroup(BaseExceptionGroup, Exception)?
Similar to the argument for "except Exception". Applications that trap KeyboardInterrupt so that they can exit cleanly without an ugly traceback will no longer trap *all* keyboard interrupts, as they could miss grouped ones.
If we accept that grouped exceptions should never escape out of a well-defined context, then this wouldn't be such an issue. But there's nothing in the PEP that enforces that, and there *is* code that needs to be prepared for "any sort of result". It's the except Exception argument again.
So code that wants to exit cleanly in the face of Ctrl-C will need to be rewritten from:
try: main() except KeyboardInterrupt: print("User interrupted the program. Exiting") sys.exit(1)
to:
try: try: main() except KeyboardInterrupt: print("User interrupted the program. Exiting") sys.exit(1) except *KeyboardInterrupt: print("User interrupted the program. Exiting") sys.exit(1)
Did I miss an easier way of writing this code? And worse, how would I write it so that it was portable between Python 3.9 and later versions (which is a common requirement for library code - admittedly library code wouldn't normally be doing this sort of top-level trap, but it could just as easily be "catch Ctrl-C and do a bit of tidy-up and re-raise").
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.
Maybe. But I'm not looking at it as being "comfortable" with the current situation, but rather as "I don't use any of these new features, why am I having to change my code to accommodate stuff I don't use?" If I own the full stack, that's not an issue, but frameworks and libraries typically have to interact with other users' code, and there the contract has changed from "do what you like in your code and I'll cope" to "do what you like in your code as long as you don't let an exception group escape, and I'll cope"... And I have to change *my* code to get the old contract back.
But it's a small point in the wider scheme of things, and I'm not going to labour the point any more. Thanks for listening and taking the time to reply.
Paul
Paul _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WSUEOGDC... Code of Conduct: http://python.org/psf/codeofconduct/