Modules implicitly exposing exceptions from other modules

[Randall Hopper]

Fred L. Drake, Jr.:
 |Jason Stokes writes:
 | > I notice that the nntplib.NNTP class can throw exceptions from the
 | > underlying socket module without documenting them.  What's good practice
 | > when your module involves exposing exceptions from an implementation module
 | > that client code might not necessarily be aware of?
 |
 |  Document them if they would not be expected by an experienced
 |programmer.  In general, all network access can throw socket.error,
 |and that seems a reasonable expectation.

I'd be stronger with this.  That is, replace "experienced programmer" with
"any programmer".

A user calling Module A shouldn't have to know what other modules Module A
uses to catch and handle any error exception that might be thrown.

My perspective: 

   There are program bug exceptions and error condition exceptions.
   Considering the latter:

   All error exceptions potentially thrown in a method should be documented
   for that method.  

   Module-specific error exceptions should be transformed as they propogate up.

The latter is so if you call Module B which calls Module A, you're only
expected to catch generic exceptions or Module B exceptions to handle any
error exceptions that may arise).  

For example, I don't think tossing broken socket Socket exceptions across
the NNTP boundary is a good idea.  How does the NNTP client catch these (or
know to catch these)?  A wildcard except clause, which catches bugs and
errors.

-- 
Randall Hopper
aa8vb at yahoo.com