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