Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passing error information though #167

Open
KantarBruceAdams opened this issue Sep 28, 2018 · 7 comments
Open

Passing error information though #167

KantarBruceAdams opened this issue Sep 28, 2018 · 7 comments
Milestone

Comments

@KantarBruceAdams
Copy link

KantarBruceAdams commented Sep 28, 2018

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
Copy link
Collaborator

henryiii commented Sep 28, 2018 via email

@KantarBruceAdams
Copy link
Author

KantarBruceAdams commented Sep 28, 2018

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
Copy link
Collaborator

CLI11 already has one, see:

CLI11/include/CLI/App.hpp

Lines 1633 to 1650 in da901cc

namespace FailureMessage {
/// Printout a clean, simple message on error (the default in CLI11 1.5+)
inline std::string simple(const App *app, const Error &e) {
std::string header = std::string(e.what()) + "\n";
if(app->get_help_ptr() != nullptr)
header += "Run with " + app->get_help_ptr()->get_name() + " for more information.\n";
return header;
}
/// Printout the full help string on error (if this fn is set, the old default for CLI11)
inline std::string help(const App *app, const Error &e) {
std::string header = std::string("ERROR: ") + e.get_name() + ": " + e.what() + "\n";
header += app->help();
return header;
}
} // namespace FailureMessage

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

@KantarBruceAdams
Copy link
Author

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
Copy link
Collaborator

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

@KantarBruceAdams
Copy link
Author

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
Copy link
Collaborator

henryiii commented Oct 5, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants