exceptions

[peterritter]

hi

I defined
#define PROGRAMOPTIONS_SILENT

and I expected to get exceptions instead of the error messages, but there were no exceptions even when I had non-option arguments. Also, I'm not sure this really needs to be a pre-processor definition. Could you not have a .verbose() member to enable std::cerr messages as well as .throw_on_error(bool) to enable/disable exceptions on error? I think by default it should throw an exception unless user sets throw_on_error(false); I definitely think that a non-option argument should result in an exception, because the app user is clearly trying to do something, and if the app can't do it, it should not ignore it. That's confusing.

I would also like to get easier access to non-option arguments, other than just via a callback. Could you not simply add a function like:

std::vector<std::string> non_option_args(void);

That way I can easily do what I want with them without callbacks.

Thanks, peter

[Fytch]

Hello

Could you not have a .verbose() member

Yes, a flag makes much more sense. In retrospect, I have no idea why I implemented it as a macro, honestly. 😆

because the app user is clearly trying to do something, and if the app can't do it, it should not ignore it

You can (and should!) always check the return value of parser::operator() as I did in this example: https://github.com/Fytch/ProgramOptions.hxx/blob/master/examples/3%20files.cxx#L34 It returns false when an error has occurred. This way, you can stop the execution and print an error message yourself.

I would also like to get easier access to non-option arguments, other than just via a callback.

It is actually possible: parser[ "" ].to_vector< po::string >() or

auto&& unnamed = parser[ "" ];
parser( argc, argv );
auto files = unnamed.to_vector< po::string >();

I expected to get exceptions instead of the error messages, but there were no exceptions even when I had non-option arguments

I think checking the parser's return value solves this problem as well, right?

On a general note: I am very thankful for your suggestions and criticism but I need some time to implement them, so I hope you're not in a rush? I am just a bit busy and all these improvements take some work and time. I hope you understand this. :)

Thanks a lot and cheers!

[peterritter]

Hi Take your time! In general the library does what I need, which is parse command line options. Everything else is a bonus. I usually like to solve a problem so well that I can reuse a lib over and over on many projects. . I'm just telling you the things that come to my mind while I am using your lib. So, don't rush, take your time, there is no urgency. Thanks for the effort.

Peter

[Fytch]

There's a member function parser::silent() implemented on the develop branch, which does what you suggested. There's also a parser::verbose(std::ostream&) that lets you redirect the output, e.g. into a log file. Commit: https://github.com/Fytch/ProgramOptions.hxx/commit/ce27c928ca758d1cc0a8f32696dba6325d746c25

Do you consider the other issue regarding exceptions resolved? I personally prefer the library automatically taking care of errors and letting me know via a simple boolean return value. What do you think?

Regards

[peterritter]

Hi

I personally prefer the library automatically taking care of errors and letting me know via a simple boolean return value

Well, this is not really about your own personal preference. You are developing a c++ library and so you need to adhere to C++'s guiding principles. In C++ an error results in an exception! Period! There is no discussion about it. Your job as a library builder is to help the developer build better code. What you are proposing is not 'taking care' but rather 'supressing' errors. You clearly thought they were errors, since you reported them on the command line. But that is not your job. Interacting with the user is something the programmer does, since he knows better than you what the app is about. So what you need to do is throw an exception derived from std::logic_error with enough information to let the developer either handle the error or write a meaningfull error message (containing name of argument causing the error).

You could also pass an enum{throw_on_error, no_throw_on_error} to the parser::parse() member function as an additional argument. But the default behavious should definitely be 'throw_on_error'. P.