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
