O 25/09/20 ás 10:02, Chris Angelico escribiu:
On Fri, Sep 25, 2020 at 5:09 PM Sergio Fenoll <ser...@fenoll.be> wrote:
O 25/09/20 ás 08:41, Chris Angelico escribiu:
It would have to not only look at get(), but everything that it calls.
Either that, or you're back to the Java thing of "catch it or declare
it", and we've seen from Java that that's a bad idea.
ChrisA
I don't really understand why those are the only options. The way I see it,
whomever implements get() can just have a list of expected Exceptions and as
a caller you just handle those (now with the added ease that you don't
need to
look them up out-of-bounds, they're already in your IDE!) and if an
unexpected
exception happens, well you handle it the same way you do it now (i.e.
either not
at all, with a bare except, or something along those lines).
Don't think in terms of "expected exceptions". That's the mentality
that leads to coding styles where you try to catch every exception the
function can raise, which is the wrong way to think about it.
Instead, think in terms of "exceptions that I can handle".
ChrisA
I see what you mean now, and I agree. But surely there's a fairly big
overlap between
"exceptions I expect to raise" (from the POV of the callee) and
"exceptions I can handle"
(from the POV of the caller). Wouldn't it still be useful to have the
first part (exceptions
I expect to raise) defined in the code (i.e., via some kind of
annotation) in such a way that
makes it easier for the caller to handle the exceptions they want to catch?
Or, in your opinion, should the callee not even have a notion of
"exceptions I expect to raise"?
_______________________________________________
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/V36GLZXCT63ODWMTRQY23VT7WUVMO6W2/
Code of Conduct: http://python.org/psf/codeofconduct/
