Hi Barry,
On Mon, Mar 1, 2021 at 6:12 PM Barry Scott <ba...@barrys-emacs.org> wrote: > > Have you considered alternative syntax to the "except*"? > I feel that expect* is too easy to confuse with plain except. > We briefly considered things like "except Group[ValueError, TypeError]". Do you (or anyone else) have any suggestions on syntax? > > As others have said needing to change all except Exception: > handlers would be a breaking change for code that I maintain. > > I think its accepted that that idiom should continue to be as > reliable as it currently is. Can you confirm that I have understood > the conversation on this point? > That's not happening. The PEP has been updated regarding this. It was never going to be all "except Exception", most of them would not be affected. But we have a better plan now so this discussion is moot. As an aside - I found it interesting that the option to wrap BaseException instances by an Exception, which came up a couple of times in this thread, didn't generate any anxiety. In my day job I maintain a proprietary DSL that ~4000 developers use, and my experience has been that a bug that swallows an exception you need is worse than a bug that makes you get an exception you did not expect. The latter can hurt you once (and then you fix it). But the former is (1) harder to detect (2) longer to debug (3) once you know about it there is nothing you can do to work around it. Problems like that cost us years and years of work. > > I have been thinking about why I would be getting an ExceptionGroup > with, for example, a number of OSError for a handler to deal with. > Would it not be a difficult piece of code to write without the context of > each OSError? > > What I'm think is that the lower level pieces would be catching the OSError > closer to the source of the problem and raising a App/Lib specific > exception > that provides the context. For example AppFailedToSaveConfigError and > AppFailedToSaveDataError as oppose to a two permission OSError's. > I think you're right about this. OSError is an example of an exception with a data field that is often inspected for its value, so we picked on it to talk about how you would do something like this. Most of the time this won't be needed, but we still need to know that it's possible and reasonably ergonomic to do it. > With context I can imagine that handling the ExceptionGroup would be > a lot easier for the App designer. > > If that the pattern that emerges then is the complexity of nested > ExceptionGroups going to only rarely used? > I can't imagine people building deep trees of exceptions in practice (at least not on purpose). But some nesting may show up naturally, and we need to support it because otherwise it can get awkward if, for example, asyncio.gather() needs to wrap an exception group that came from a TemporaryDirectory.__exit__(). Irit
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/3W6C3Y6WVKGYL4H63VDLB7VF6JH52TV4/ Code of Conduct: http://python.org/psf/codeofconduct/
