A side benefit is that if an Exception somehow propagates up where only ExceptionGroup is defined, except *() could just work anyway, though it might take a little magic to make sure they act the same. Like Guido said, I don't think it can be retrofitted into existing *-less APIs, and it'll either need a new API and deprecation, or dumping the old for the new hotness if that's the maintenance strategy, but as long as docs call out that this is now returning collective exceptions, I don't see a problem.
I don't think it's been mentioned, but it's a nice synergy with pattern matching, even if it's wholly unrelated, and having both in one release will actually make sense.
On Fri, Feb 26, 2021 at 6:45 AM Nathaniel Smith firstname.lastname@example.org wrote:
On Fri, Feb 26, 2021 at 5:05 AM Irit Katriel email@example.com wrote:
I'm not sure it's safe to assume that it is necessarily a programming
error, and that the interpreter can essentially break the program in this case.
Is this not allowed?
try: try: obj.func() # function that raises ExceptionGroups except AttributeError: logger.info("obj doesn't have a func") except *(AttributeError, SyntaxError): logger.info("func had some problems")
I'd be fine with disallowing that. The intuition is that things will be simplest if ExceptionGroup is kept as transparent and meaningless as possible, i.e. ExceptionGroup(ValueError) and ValueError mean exactly the same thing -- "some code inside this block raised ValueError" -- and ideally should be processed in exactly the same way. (Of course we can't quite achieve that due to backcompat issues, but the closer we can get, the better, I think?)
If you need to distinguish between the AttributeError from 'obj.__getattr__("func")' vs the AttributeError from the call to func(), then there's already an obvious way to do that, that works for all functions, not just ones that happen to raise ExceptionGroups:
try: f = obj.func except AttributeError: ... try: f() except ...: # or except *...: ...
-- Nathaniel J. Smith -- https://vorpus.org