On Saturday, February 18, 2012 16:36:16 H. S. Teoh wrote: > On Sat, Feb 18, 2012 at 05:13:16PM -0600, Andrei Alexandrescu wrote: > > On 2/18/12 4:26 PM, Jonathan M Davis wrote (abridged): > > GetOptException > > FlagArgumentMissingException > > InvalidFlagArgumentException > > UnknownFlagException > > FileException > > FileNotFoundException > > NotFileException > > NotDirException > > AccessDeniedException > > > > I died inside a little. > > [...] > > That's because you're missing the hierarchy, which may look more like > this: > > Error > +--Exception > +--GetOptException (bad name, I prefer CommandLineException) > > | +--FlagArgumentMissingException > | +--InvalidFlagArgumentException > | +--UnknownFlagException > > +--FileException > > | +--FileNotFoundException > | +--NotFileException > | +--NotDirException > | +--AccessDeniedException > > +--IOException (OK, I added this branch, just to show the idea) > +--ReadErrorException > +--WriteErrorException > > So if all you care about is to handle command-line option parse errors, > and don't care which error it is, you could just catch GetOptException. > If all you care about is file access exceptions, you can just catch > FileException without having to worry which specific exception it is. > > Alternatively, if you don't care which exception it is at all, then > just catch Exception. > > That's the whole point of a (well-designed) exception hierarchy. It lets > you be as generic or as specific as you want. > > 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. > > Similarly, GetOptException (or CommandLineException) may have additional > fields to indicate which option is malformed. Such information, > obviously, shouldn't be in other kinds of exceptions but those that > inherit GetOptException.
Exactly! And in order to programmatically handle exceptions rather than simply print out messages, that hierarchy and the extra information that the derived exceptions give is necessary. - Jonathan M Davis
