The Right Approach to Exceptions

[Jonathan M Davis]

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