Re: [boost] Re: new exception design guideline

From: Daron Anderson (dnanderson_at_[hidden])
Date: 2003-09-06 11:54:26

-----Original Message-----

>> Maybe I am not seeing this from the right perspetive, but wouldn't a
better
>> design guideline be not to use multiple inheritance at all in an
exception
>> hierarchy?  I do not see any reason that any exception would have an IS-A
>> relationship with any two parent classes.  I view an exception of being a
>> very specific error, but multiple inheritance implies that the exception
is
>> simultaneously two types of errors.
>
>Quoting from Section 14.2.2, The C++ Programming Language, 3rd edition
>(Bjarne Stroustrop):
>
>Not every grouping of exceptions is a tree structure.  Often, an exception
>belongs to two groups.  For example:
>
>class Netfile_err : public Network_err, File_system_err { /* ... */ };
>
>Such a Netfile_err can be caught by functions dealing with network
>exceptions:
>
>[code snippet elided]
>
>and also by functions dealing with file system exceptions:
>
>[code snippet elided]
>
>This nonhierarchical organization of error handling is important where
>services, such as networking, are transparent to users.  In this case, the
>writer of [the code handling file system exceptions] might not even be
aware
>that a network is involved.

I have spent some time thinking about this response, but still don't see
that a benefit exists for multiple inheritance in exception hierarchies.  I
would like to state my simple opinions and ask that other people point out
concerns and problems with my veiwpoint.  I have a sincere desire to
understand this issue from other people's perspectives so that I can better
understand all the facts about these different designs (single vs. multiple
inheritance in exception hierarchies).

While I have great respect and admiration for Dr. Stroustroup and his work,
I don't see the justification of an exception representing both a network
error and a filesystem error in this example.  If a network error occurs, I
would like it to be caught by "catch( Network_err & x)", since I am
explicitly 'watching' for network errors in that location.  Similarly, I
would "catch( File_system_err & x)" to catch only file system errors.  If I
attempt to catch a Netfile_err exception, I still don't know exactly what
type of error was caught.  I would rather have code that catches each type
of error separately, giving me the ability to deal with them based on the
source of the error (the network was down vs. a corrupt file system).

Also, I feel that it might be misleading for a Netfile_err that was
generated because of a network error to be caught using
catch( File_system_err & x )".  While the code will probably do some
recovery and continue running, it would probably be coded to recover from a
file system error.  For instance, it might attempt to retry the operation
that caused the exception, not knowing that a remote system's network card
has failed and is now unreachable.  This type of error correction can lead
to unexpected behavior and delays that would make your software look less
appealing to a customer (possibly).  In the cases where the writer of client
code might not be aware that a network is involved, I don't see that they
are really helped in this situation (they have, in fact, handled the wrong
type of error.)

My personal opinion is that the developers of client code
would be better off in this case if they could guarantee that
catch( std::exception& x )" would act as a catch-all handler that gave them
the ability to read the what() string and determine that they need to catch
a new type of exception (which may require some research time to find out
all the exceptions that can be thrown by the libraries they are using, but
gives them better overall understanding of the library they are using and
the services the library provide.)  This way, errors are caught with as much
granularity of type as the exception hierarchy can allow.  To me, this is
the most important benefit of exceptions: to deal with errors by type.