🚀 go-pugleaf

In article <1992Sep30.205656.10646@lucid.com>, jss@lucid.com (Jerry Schwarz) writes:
|> 
|> At the moment X3J16 is considering the implications of exceptions
|> for stream classes.  Some think that streams should only
|> be able to throw a particular kind of exception (tentatively
|> named ios::failure). Others (including myself) feel that a stream
|> should be able to throw an arbitrary exception. Remember, users
|> can define their own kinds of streambufs, so X3J16 can't know in advance
|> what kinds of conditions they might want to report.  
|> 
|> My intuition (not based on experience I confess) is that in
|> general it is more important to get specific information about
|> the conditions that caused an exception than it it to know that
|> it in occured in some stream operation. That is, it is better to
|> know that there was an "out of memory" or "database corruption" problem
|> than it is to know that there was a problem while doing a stream
|> operation.  This leads me to the conclusion that the iostream library
|> should not use failure clauses.

One thing that bugs me about having "lots" of exception types that could be
thrown is the degree of coupling that will result between parts of the program.

If an object can throw 18 exception types, then clients will need to understand
all those types, and their implications -- and perhaps then, something of the
internal workings of that object, in order to understand how to respond to a
particular exception.

It might be better to cause the functions in the objects interface (the top
level functions of the object) to throw only a limited set of exceptions, perhaps
only one, and handle all other exceptions themselves (print an error message or
log, take some constructive action, etc.).  The client's response to failure
of an object might be to destroy and recreate the object, and reattempt the
operation, or call a "recover" function in that object, etc.

There is a measure of philosophical difference here.  If all parts of the program
are written by the same team, then the team can determine the safe degree of 
coupling between objects and their clients.  On the other hand, if a program is
to be created from reusable (perhaps third-party) software libraries, then coupling
should be minimized -- otherwise, why use objects at all?

-- 
Matt Holiday                                         #include <std/disclaimer>
holiday@bnr.ca
BNR Richardson, TX