On 2020-09-26 01:23, Greg Ewing wrote:
On 26/09/20 4:32 am, Oscar Benjamin wrote:
annotations could be used to document in a statically
analysable way what the "expected" exceptions are. A type checker
could use those to check whether a caller is handling the *expected*
exceptions
But that would be inappropriate. Even if an exception is
"expected" (assuming for a moment we agree on what that means),
the immediate caller is *not* obliged to handle it. Just as
with any other exception, it's perfectly fine to let it propagate
up to a level where something sensible can be done with it.
Treating this as an error would be more annoying than helpful in
most situations, I think.
There are a few cases where it *might* make sense, such as
StopIteration, which is pretty much part of the function's API
and letting it escape is probably a mistake. But such cases
are very rare and probably not worth adding a new language
mechanism for.
An "expected" exception would be one that could be regarded as part of
the interface/API, e.g. json.load raising JSONDecodeError on malformed
JSON. Other exceptions could also be raised, if you, for example, you
didn't pass in a file, or there's an I/O error, or you run out of memory.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/TQBQMSHAZDM5YVI4HQGLVJUQXZ47QQS7/
Code of Conduct: http://python.org/psf/codeofconduct/
