Modules implicitly exposing exceptions from other modules

[Tres Seaver]

In article <20000215085250.A2423951 at vislab.epa.gov>,
Randall Hopper  <aa8vb at yahoo.com> wrote:
>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.

While your main point is fairly strong, your example is weak.  Anybody
writing an NNTP client who *doesn't* expect to handle socket errors is asking
for trouble.  There is nothing useful to be done about them at the "mechanism
level" (in nntplib);  they need to be dealt with at the "policy level" (the
client).  Any munging of the exception in nntllib is going to be lossy, which
is intolerable for many applications.

Leaving the handling of such errors to the client also simplifies the
mechanism library (nntplib), making it less likely to be buggy.  This simplfi-
cation is one of the chief benefits of exceptions over return codes:
intermediate layers, which have no reasonable means to handle an error, simply
ignore it.

Ignorance-is-bliss'ly,

Tres.
-- 
---------------------------------------------------------------
Tres Seaver           tseaver at palladion.com       713-523-6582
Palladion Software    http://www.palladion.com