Passing error information though

[KantarBruceAdams]

Hi, I wanted to adapt the output from CLI11 to match my local standard, which is Unix style. So instead of:

The following arguments were not expected: foo bar

I want:

MyProgram: error: unexpected arguments "foo", "bar"

and instead of:

The value Foo is not an allowed value for -Bar

I want:

MyProgram: invalid usage, "Foo" is not an allowed value for option "--Bar"

I thought no problem I can simply catch the exceptions and translate them. This is not possible as the exception classes such as "ConversionError" construct the message but do not preserve the parameters needed:

ConversionError(std::string member, std::string name)
    : ConversionError("The value " + member + " is not an allowed value for " + name) {}

It would be a simple change to make "member" and "name" member variables of the exception class for this and the other errors. Would a pull request making this change be accepted (assuming I can find the time)?

Regards,

Bruce.

[henryiii]

You could do that, and it would be acceptable, but is not the correct solution in this case. You can write an new error message formatter FailureMessage::Unix and that would be a great PR too.

We also should move the failure formatter functions out of App.hpp.

[KantarBruceAdams]

I agree an error formatter is a better solution but its harder to get the information into it. We would need to replace throwing of exceptions relating to parsing with an error formatter interface or do you have some other suggestion?

[henryiii]

CLI11 already has one, see:

https://github.com/CLIUtils/CLI11/blob/da901cca542612a133efcb04e8e78080186991e4/include/CLI/App.hpp#L1633-L1650

You can add one of those to the App (simple is the default).

[KantarBruceAdams]

I think it would require both. The simple formatter just uses the exceptions anyway. So the information needs to be in the exception class for the formatter to use. failure_message() is only used by the exit() method which I overlooked (mistakenly thinking it might exit the program).

[henryiii]

Okay, adding the info to the exception would be a useful PR.

[KantarBruceAdams]

I'm not sure if or when I will have time to work on this now. #166 was a non-starter for my use case. so I ended up rolling my own parser as normal.

[henryiii]

I’ll work on this at some point unless you get to it first. And #166. Just short on time for a while.