The Right Approach to Exceptions

Jonathan M Davis jmdavisProg at
Sun Feb 19 04:29:43 PST 2012

On Sunday, February 19, 2012 12:43:12 Jacob Carlborg wrote:
> On 2012-02-18 23:26, Jonathan M Davis wrote:
> > In the case of getopt, what we want is a GetOptException which is for
> > anything which goes wrong with getopt so that someone can catch that
> > exception type if they want to just handle the case wheree getopt throws
> > but don't want to swallow other exception types by calling exception and
> > pretty much just want to print an error and exit the program or continue
> > without any comand-line arguments if that's what they prefer to do.
> Isn't that what CommandLineException would be? Or would "getopt" throw
> other exceptions that would not derive from CommandLineException? So we
> end up with this:
>              GetOptException
>                 /      \
>                /        \
>               /          \
> CommandLineException  SomeKindOfOtherException

IF you want to call it CommandLineException rather than GetOptException, 
that's fine. I don't much care. The name isn't the critical part here. 
GetOptException would be more in line with how we've been naming things, but 
CommandLineException would be more reusable by code outside of std.getopt, so 
it's probably better. The critical thing here though is that getopt throw an 
exception (or exceptions) which actually give you the information that you 
need to handle the problem, which isn't the case right now.

- Jonathan M Davis

More information about the Digitalmars-d mailing list