Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Command validators don't seem to use the default value factory of an Option

Open
  • Is something wrong?
#2,841 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
csharp
Domain
cli

Research direction

Start by tracing how command-level Validators use result.GetValue(_multiplier) and how an Option's DefaultValueFactory is applied. Compare that behavior with option-level validators and GetValueOrDefault(); done means the intended handling of omitted options is established and the observed discrepancy is covered by the relevant validation behavior.

Written by the indexing model from the issue text.

Description

I've been on 2.0.0-beta4 for a while, and only recently gotten around to update to 2.0.10. One of the more interresting changes has been how validations work. It bugged me that I only had a single error message return and had to join multiple ones myself if there was more than one issue; but new API with result.AddError makes this a lot nicer.

However, I noticed that my old command-level validator didn't work anymore:

internal sealed class MySubCommand : Command
{
  private readonly Option<int> _multiplier = new("-m", "--multiplier") { Description = "Value multiplier, must be a positive non-zero value", DefaultValueFactory = _ => 1);
  public MySubCommand() : base("mysub", "Babies first subcommand")
  {
    Add(_multiplier);
    Validators.Add(result =>
    {
      if (result.GetValue(_multiplier) <= 0)
        result.AddError("Multiplier must be greater than 0.");
    });
    SetAction(Handle);
  }
  public int Handle(ParseResult parseResult) { /* ... */ }
}

As it turns out, that would return 0 (the default value for int) rather than what DefaultValueFactory would give me.
The -m argument is generally optional; but when it's specified I need it to be positive/non-zero.

In my case though, the fix is simple: Put the validation on the option itself (which wasn't a thing before; or I just overlooked it):

-    Validators.Add(result =>
+   _multiplier.Validators.Add(result =>
     {
       if (result.GetValue(_multiplier) <= 0)
         result.AddError("Multiplier must be greater than 0.");
     });

(Which could even go and use result.GetValueOrDefault<int>() instead, since it's specific to the option that way.)

In 2.0.0-beta4, this was simply:

AddValidator(result =>
{
  if (result.GetValueForOption(_multiplier) <= 0)
    result.ErrorMessage = "Multiplier must be greater than 0.";
});

(Which felt straight-forward to migrate over, since there was no real mention of this behavior in the 2.0.0-beta5 migration guide. And the fact that I had to keep my own error list if I did more than one validation in there; but I omitted that for brevity.)

And that made me wonder: Since command-level validations are intended for cross-argument checks (like, if related arguments like ranges or from/to etc. are passed; whether they work in combination), wouldn't this potentially cause subtle bugs if someone expected the result to be as produced by the DefaultValueFactory? Is this the intended behavior of the command-level validator?

Dominant language
C#
Stars
3.7k
Forks
432
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/command-line-api

All issues in dotnet/command-line-api

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.