O 25/09/20 ás 10:56, Chris Angelico escribiu:
There's the shallow "exceptions that I expect to raise", which is
those explicitly listed within the function as raise statements; but
that's not the whole story, since exceptions can be raised by anything
that the function calls. So, no, I don't think the callee should have
a notion of "exceptions that I or anyone I call might raise".
ChrisA
I don't understand the need of talking about "exceptions that something
I call might raise" (from the POV of the callee) though, to me they are
irrelevant in this discussion. When you implement a function, you are
handling all/some/none exceptions and letting all/some/nonebubble up and
be handled by whatever called you, right? Somewhere, be it in a
docstring, some manual, external documentation, ... you write down what
exceptions you expect to raise, be it explicit or implicit (e.g. by
letting a known exception bubble up without explicitly raising it
yourself). I'm basically only talking about those kinds of exceptions
here, because in my experience those are the exceptions I'm most often
having to try-except. Sure, as a caller you may want to handle more
exceptions than what the callee sees as "expected exceptions", but
nothing will stop you from doing that just as you do it now. I don't see
how having these exceptions be annotated in the code makes anything
worse. From my perspective it just makes the most common try-except
you'll write easier to implement without having to leave the IDE and
check external documentation.
_______________________________________________
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/AUESIFXSGGBAZIJBRBAHJ3UFOODR233I/
Code of Conduct: http://python.org/psf/codeofconduct/
