How to change format of error output

[fritzrehde]

By default, clap will output something like e.g. error: One of the values isn't valid for an argument if an invalid argument was provided. Is there a way to customize the format of this output? Could I somehow reach my custom error message prefix: One of the values isn't valid for an argument?

[epage]

You can call clap where it returns the error, instead of directly exiting (the method depends on whether you are using Builder or Derive). You can then apply a custom ErrorFormatter and then call exit.

If you want formatted text in your error, we don't support that yet (see #3108) so you would instead get the error, directly format and print it, and then exit on your own (or apply a no-op formatter and call exit).

[fritzrehde]

You mentioned you "don't support that yet". Does the "yet" imply that the use-case I described is being worked on and will be in clap in the future? If so, I am fine just waiting until then, I don't need this feature asap.

[epage]

We support custom error messages now. You just have to do extra hoops if you want it to be colored, bolded, etc. User provided formatting is the highest priority for clap. I just need to wrap up some toml / toml_edit stuff and then I'm going to come back to it.

[fritzrehde]

The reason I asked this in the past was because I use anyhow in my CLI project as well, and that prints most errors to the terminal, besides the clap ones. Until now, I have used the derive version of clap with:

        let cli = ClapConfig::parse();

where ClapConfig is the struct I am parsing into. This caused the program without going through anyhow on CLI parsing errors (e.g. unknown option -d). However, when I tried to add:

        let cli = ClapConfig::try_parse().context("Failed to parse CLI arguments")?;

The help message (cargo run -- --help) is also recognized as an error. Is this a bug, or intentional? I guess returning an error is the only way to interrupt the control flow to print the help string. But it does seem a little unintuitive. Any tips on how I can use clap together with anyhow well?
Otherwise, I'm actually also fine with the error messages looking a little different (between clap and anyhow), there are more important things :)

[epage]

Is this a bug, or intentional?

That is intentional. As you said, errors in CLI aren't always about failures but early termination. You can use use_stderr to determine whether --help or --version is being processes and handle them differently

Any tips on how I can use clap together with anyhow well?

Otherwise, I'm actually also fine with the error messages looking a little different (between clap and anyhow), there are more important things :)

I recommend opening up with problem statements in the future (I want my clap and other CLI errors to look more alike) so we can better navigate what means best help accomplish that. And ideally that would come with images so we can evaluate the value of converging (FYI I think this is the first time someone requested help in wanting to make them more alike)

You could possible

let cli = match ClapConfig::try_parse() {
    Ok(cli) => cli,
    Err(err) => {
        if err.use_stderr() {
            ... wrap with anyhow
        } else {
            err.exit();
        }
    }
};

However, I don't know if that would actually do a good job of making the errors good.

[ofek]

You can use use_stderr to determine whether --help or --version is being processes and handle them differently

I'm facing the same dilemma. How would one go about that exactly? Would it be just a naïve search through the os_args or is there a better way? And when that happens how would I relinquish control back so that the help text is shown rather than my custom error logic?

[epage]

I gave a code example above that shows how to use use_stderr so --help and --version don't bubble up as normal errors.

Is there something else you are looking for with your question? If so, it might help if you gave more details about your scenario.

[ofek]

Based on your answer it was unclear to me that the result of use_stderr was synonymous with one of those flags being passed, but it appears that is indeed the case and it's as simple as that! Here is what I've done: ofek/pyapp#61

I'm not sure if this is intentional but not passing any arguments counts as an error which is perfect for my use case where I want app self to not show the wrapper help text of the root command group but actually pass straight through to the underlying self command. Hopefully that behavior doesn't change 😄

[epage]

I'm not sure if this is intentional but not passing any arguments counts as an error which is perfect for my use case where I want app self to not show the wrapper help text of the root command group but actually pass straight through to the underlying self command. Hopefully that behavior doesn't change 😄

When the derive API sees that a subcommand is required, it implies both Command::subcommand_required(true) and Command::args_required_else_help. I'm assuming what you are seeing is from the latter. So far it seems like the behavior that makes the most sense (and no one has complained) but even if we change that default for the derive, you can always enable it manually.