On 2/18/2012 3:13 PM, 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.
Andrei
IMHO, I would not have made a GetOptException at all. It is too specific
to the function. Since this is a type of parse error, I would prefer a
ParseException base class. I think has a couple of advantages. One, the
same exception can be used not only by the library itself but also by
other users. Parsing is not an uncommon activity. Two, the exception
hierarchy is orthogonal to the library. So changing the library
functions---adding or removing them--- doesn't require changes in the
exception hierarchy. Perhaps ParseException could then have a field that
highlights the text that could not be parsed. This could be generally
for all parsing type application.
In separating what should be a distinct type from what should be an
attribute, I'd think you can use as a guideline whether the errors are
likely to be handled in one place. I would guess that if you're going to
try to analyze a parse error you would handle the possibilities of
FlagArgumentMissingException, InvalidFlagArgumentException, and
UnknownFlagException all in one place. You're not likely to catch one
and let the others propagate upward. So those could be attribute you
handle with a switch rather than separate types.
Jim
