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

It seems like a compromise -- making ios::failure into a base class
from which other more specific exception types can be derived -- would
be the best approach.  Application code that can do something useful
with specific exceptions can then arrange to catch each one
individually, while code that cares only that an exception was thrown
but does not wish to catch each different type can arrange to catch
only the base class.

-steve
-- 
Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.