Command validators don't seem to use the default value factory of an Option
还没有人认领这个 Issue。
评估
调研方向
首先跟踪命令级 Validators 如何使用 result.GetValue(_multiplier)，以及 Option 的 DefaultValueFactory 如何应用。将该行为与选项级验证器和 GetValueOrDefault() 进行比较；完成后，省略选项的预期处理方式就得以确定，并且观察到的差异也由相关的验证行为覆盖。
由索引模型根据 Issue 内容生成。
描述
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?
- 主要语言
- C#
- 星标
- 3.7k
- 派生
- 432
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
dotnet/command-line-api 的其他 Issue
-
German localization is incomplete可能已有人在做 @b-v-d-e-v 于 3 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 65/100
dotnet/command-line-api#2852 ·
-
Incomplete French (fr) translation: RequiredOptionWasNotProvided not translated可能已有人在做 @JPBlanc 于 101 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 65/100
dotnet/command-line-api#2822 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 62/100
dotnet/command-line-api#2792 · 2 条评论 · 15 个 reaction ·
-
难度 2/5 1-3 小时 新手友好度 62/100
dotnet/command-line-api#2704 ·
-
GetCompletions should check exit code of invoked application可能已有人在做 @baradgur 于 1272 天前认领。 未关闭Area-Completions bug help wanted
难度 2/5 1-3 小时 新手友好度 72/100
dotnet/command-line-api#2137 · 1 条评论 · 3 个 reaction ·
查看 dotnet/command-line-api 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
PCL-Community/PCL-CE#3652 ·
维护者通常 1 天内回复
-
area:frontend bug FE P3
难度 2/5 1-3 小时 新手友好度 68/100
klasolsson81/jobbliggaren#2010 ·
维护者通常 1 天内回复
-
agentic-workflows untriaged
难度 1/5 1 小时以内 新手友好度 65/100
维护者通常 1 天内回复
-
area: homeblaze type: bug
难度 2/5 1-3 小时 新手友好度 74/100
RicoSuter/Namotion.Interceptor#630 ·
维护者通常 1 天内回复
-
Akka.Hosting enhancement
难度 2/5 1-3 小时 新手友好度 65/100