The Right Approach to Exceptions
Jim Hewes
jimhewes at gmail.com
Sun Feb 19 14:53:04 PST 2012
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
More information about the Digitalmars-d
mailing list