Modules implicitly exposing exceptions from other modules

[Randall Hopper]

Tres Seaver:
 |Randall Hopper:
 |>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.

No, you miss the point of my example.  I didn't say "socket", I said
"Socket".  NNTP could be built on Socket, or FastSockets, or TLI, or
MasGreatestSocketModule, all of which could have a different exception
structure.  

For example, someone may decide later to switch NNTP over from Socket to
FastSockets.  NNTP would be revised in the process.  Clients which call
NNTP and handle all exceptions passed up from NNTP shouldn't have to break
because of this internal dependency change.  If the exceptions are
transformed at the module boundary by NNTP, clients needn't break.

My whole point is that error exceptions are part of the function signature,
just like arguments and return values.

 |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).

Except in cases where the mechanism level needs to do cleanup, I agree
(assuming we regard abstraction as "not useful").

The situation is no different than say, in C, returning an instance of a
private class by value through a public interface.  By doing so we've just
made it public.  It's now part of the function signature, so clients may
break if we change it.

-- 
Randall Hopper
aa8vb at yahoo.com