On Fri, 26 Feb 2021 at 23:36, Jim J. Jewett <jimjjew...@gmail.com> wrote:
> Whenever I've used except Exception or stronger, it was a sanitary
> barrier around code that might well do unpredictable or even stupid
> things. Adding a new kind of exception that I hadn't predicted --
> including ExceptionGroup -- would certainly fit this description, and
> I want my driver loop to do what I told it.
This is my concern as well. I've got plenty of "except Exception" and
IMO none consititutes "abuse" - they're there for the same reason Jim
cites above: a barrier around _arbitrary_ callback code - so that the
outer control facility continues to roll on as expected.
All of these are handler frameworks for use by other code - they
inherently call an unknown and arbitrary thing at some point and expect
to catch an Exception raised and suitably handle it (log it, record it
for the caller to see later, whatever).
Now _all_ those handlers will need a special except* handler for
ExceptionGroup, because they DO NOT KNOW whether the called code might
raise it. And "except Exception", the longstanding recommended way to
catch "everything (well almost everything)" no longer works.
Now, I've long wanted something like MultiError or ExceptionGroup to
gather miltiple failures for raising together at a suitable
slightly-later point.
[...]
On 27Feb2021 19:06, Guido van Rossum <gu...@python.org> wrote:
>Our goal for the PEP is that *unless* you're going to use APIs that are
>documented to raise ExceptionGroup, you won't have to use `except *` nor
>will you have to deal with ExceptionGroup otherwise.
But.. this isn't Java, where the (hah!) type annotations document the
exceptions it raises.
Jim again, catching Exception to protect calling code:
>> def safe_fn():
>> try:
>> do_something_funky()
>> return True
>> except Exception:
>> print("Well, that was a shame...")
>> return False
>>
>> then I am intending to guarantee that calling safe_fn() will never
>> raise an exception. [...]
Guido:
>The modification I proposed where we have both BaseExceptionGroup and
>ExceptionGroup will satisfy this need. It basically means that *unless* you
>are explicitly using an API that is documented to raise
>[Base]ExceptionGroup (such as a future variant of asyncio.gather()), you
>don't have to care about it. [...] that's why I am proposing to change the PEP
>so that your
>code will remain safe.
That would be welcome to me, too.
Cheers,
Cameron Simpson <c...@cskk.id.au>
_______________________________________________
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/IKGK5YEPUPPWCAQ6NQEVGMKA63KPFUJQ/
Code of Conduct: http://python.org/psf/codeofconduct/
