The Right Approach to Exceptions
Jonathan M Davis
jmdavisProg at gmx.com
Sat Feb 18 18:45:16 PST 2012
On Saturday, February 18, 2012 20:28:32 Andrei Alexandrescu wrote:
> On 2/18/12 6:36 PM, H. S. Teoh wrote:
> > Note also, that an elaborated exception hierarchy lets you attach
> > additional specific information that might be useful in error recovery.
> > For example, FileException may have a field containing the filename that
> > caused the error, so that if the program is processing a list of
> > filenames, it knows which one went wrong. You would not want such
> > information in Exception, because it only applies to FileException's.
> If an exception adds state and/or interface to the table, I agree that
> may justify its existence as a distinct type.
If all you're arguing is that something like StringException shouldn't exist
because it doesn't add any additional member fields, then that's a much more
reasonable thing to debate. I'm not quite sure I agree, but some of your
responses seem to indicate that you don't want a rich exception hierarchy.
In the case of getopt, at _least_ adding a GetOptException with a field for the
failed flag would be very valuable, and having additional derived types which
indicate _why_ it failed would also be valuable. And in some cases at least,
that would lead to more member fields in the derived exceptions (like the value
of the flag if it were given a bad value).
I would argue however that there _are_ times when having a derived exception
which has no additional data beyond its type rather than simply Exception can
be useful - _especially_ when it's at the base of a larger hierarchy. For
instance, if we had an IOException, you could know that whatever operation you
were trying to do went badly because of an IO problem. You would probably need
to handle it as a subclass of IOException to get any particularly useful
information on how to handle the problem, but just knowing that it was an I/O
problem could be enough in some cases.
I really think that whether adding an exception type which adds no additional
member fields is a good idea should be evaluated on a case-by-case basis. We
don't want to needlessly create a bunch of useless, uninformative exception
types, but be we also want a rich enough exception hierarchy that it's
possible to intelligently recover from exceptions.
- Jonathan M Davis
More information about the Digitalmars-d