How do I know all thrown exceptions of a function?
Donn Cave
donn at u.washington.edu
Mon Jan 22 17:19:29 EST 2001
Quoth Randall Hopper <aa8vb at yahoo.com>:
| Fredrik Lundh:
|| Sean Reifschneider wrote:
||> Yeah, I suppose so. I don't think you should *HAVE* to review the code of
||> the libraries you call, AND *EVERYTHING* that *THEY* call. It's not an
||> effective use of my time...
||
|| yeah, and what's worse, having to *TEST* your code before
|| shipping just sucks...
|
| Like Steve, I think this is a bit too harsh. What exceptions a public API
| can throw is part of its interface, just like parameters and return values.
|
| In Python's present form which is light on strict definitions, this is
| arguably not a big issue. But in the future when typing is added to
| interfaces, exceptions need to be included in that signature.
What about exceptions raised by dependent APIs? I mean, suppose for
example that the exceptions raised by the file object, or the sys
module, changes in Python 2.1; your API is now liable to raise a
new exception thanks to those changes. Are you supposed to account
for that as part of your API? In the same release, or later when
you find out about it?
I agree that an interface does include exceptions, but it isn't so
clear how much can reasonably be specified. Exceptions generated
in the immediate vicinity is one thing; "all thrown exceptions of
a function" is another.
| Groveling through library code for rare exception conditions (initially,
| and for each dependency version update) isn't a productive use of a
| developer's time.
Certainly not, and to me exception handling feels like the most
unfinished part of Python. Unfortunately I don't have any real
ideas about it, I just find exception handling relatively error
prone when it should be the opposite.
Donn Cave, donn at u.washington.edu
More information about the Python-list
mailing list