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

Ability to modify exception messages #984

Open
levi-de-koning opened this issue Jan 22, 2024 · 1 comment
Open

Ability to modify exception messages #984

levi-de-koning opened this issue Jan 22, 2024 · 1 comment

Comments

@levi-de-koning
Copy link

We are using CLI11 for an app. We have done a lot of tinkering with the output. One of the things we ran into during this was the lack of control for the formatting of exceptions. A lot of my problems are similar to the problems mentioned in issue 167

Take the following code in app.cpp:

    if(min_num > collected) {  // if we have run out of arguments and the minimum was not met
        throw ArgumentMismatch::TypedAtLeast(op->get_name(), min_num, op->get_type_name());
    }
    CLI11_ERROR_DEF(ParseError, ArgumentMismatch)
    CLI11_ERROR_SIMPLE(ArgumentMismatch)
    ArgumentMismatch(std::string name, int expected, std::size_t received)
        : ArgumentMismatch(expected > 0 ? ("Expected exactly " + std::to_string(expected) + " arguments to " + name +
                                           ", got " + std::to_string(received))
                                        : ("Expected at least " + std::to_string(-expected) + " arguments to " + name +
                                           ", got " + std::to_string(received)),
                           ExitCodes::ArgumentMismatch) {}

    static ArgumentMismatch AtLeast(std::string name, int num, std::size_t received) {
        return ArgumentMismatch(name + ": At least " + std::to_string(num) + " required but received " +
                                std::to_string(received));
    }

As you can see here, the entire context is essentially lost as everything is combined into a string, making it incredibly difficult to modify this at a later stage.

So, for me, the solution would be either what is mentioned in the original issue and store information in the exception about the context, or what I think would be even better is to allow the user, like for many other things, to specify a callback for these default build in errors. So, the user gets the ability to build the desired output format.

@phlptp
Copy link
Collaborator

phlptp commented Jan 23, 2024

That is kind of an interesting idea (exception callbacks), Might explore that a bit further once we get the upcoming release out.

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

No branches or pull requests

2 participants