Fixing valid options for std.getopt

[Jonathan M Davis]

On Thursday, August 11, 2011 14:16 Jens Mueller wrote:
> 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.

std.log may be able to help, but getopt really doesn't have anything to do 
with logging. The primary issue is that it's currently very difficult to 
programmatically handle failures from getopt. It's difficult to do much better 
than print the exception message or that there was a general failure. To be 
able to programmatically handle the failure, you need specific stuff like 
which flag failed, what value it was given, and why it failed. When all you 
really have is the type of the exception and its message, it's not really 
enough to handle it programmatically.

- Jonathan M Davis