Fixing valid options for std.getopt

[Jens Mueller]

Jonathan M Davis wrote:
> On Thursday, August 11, 2011 10:02:38 Jens Mueller wrote:
> > Jonathan M Davis wrote:
> > > On Wednesday, August 10, 2011 15:28 Jens Mueller wrote:
> > > > D's getopt is actually modeled after Perl's Getopt::Long
> > > > (http://perldoc.perl.org/Getopt/Long.html). Linux's getopt is
> > > > actually
> > > > different in the details but I believe D's getopt is easy to use in
> > > > comparison.
> > > 
> > > Well, D's getopt should be fairly standard it terms of default behavior,
> > > and it should be reasonably easy to use. As it stands, it's pretty easy
> > > to use. I think that my main gripe is
> > > http://d.puremagic.com/issues/show_bug.cgi?id=5228 , but better sorting
> > > out its behavior like you're doing is a definite improvement IMHO.
> > 
> > Didn't know of this report. There are also other regarding getopt that I
> > should check.
> > I will have a look when I'm finished with the current changes. Since the
> > report is concerned with exception reporting it'll be nice to have some
> > specific examples where the thrown exception is not good enough. Maybe
> > you can add the specific usage examples that you found.
> 
> I'd have to mess around with getopt for a bit to get a good feel for exactly 
> what I'd like out of a specific exception, but the prime example would be that 
> a GetOptException would be able to tell you exactly which flag failed and what 
> the value was that was used with it. A ConvException is incredibly generic 
> about the problem. If I had
> 
> --flag=stuff --option=stuff
> 
> and one of those was supposed to take an int instead of a string, then the 
> ConvException is only going to tell you what the string was that faild to 
> convert - not what flag it was for - and regardless, it doesn't tell you in a 
> way that's easy for the program to determine what happened.

I see.

> Ideally, _no_ exceptions would be seen by the user, and for the program to be 
> able to give the user adequate feedback on which flag failed and why it failed, 
> the program needs an exception which actually tells it what failed and why. 
> Right now, all it gets is that a conversion in one of the flags failed, which 
> just doesn't cut it if you want to figure out what went wrong so that you can 
> give the user decent feedback.

Turning the exception into a useful message could be actually done by
std.log. In release mode std.log's format string may be changed. But
there are other options as well. I will look into providing more useful
exceptions which are needed either case.

Jens