Command validators don't seem to use the default value factory of an Option
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 52/100
Direzione di ricerca
Inizia tracciando come i Validators a livello di comando usano result.GetValue(_multiplier) e come viene applicato il DefaultValueFactory di un'Option. Confronta questo comportamento con i validatori a livello di opzione e con GetValueOrDefault(); in questo modo viene stabilita la gestione prevista delle opzioni omesse e la discrepanza osservata è coperta dal comportamento di convalida pertinente.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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?
- Lingua principale
- C#
- Stelle
- 3.7k
- Fork
- 434
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di dotnet/command-line-api
-
German localization is incompleteForse già presa @b-v-d-e-v l’ha presa 6 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
dotnet/command-line-api#2852 ·
-
Incomplete French (fr) translation: RequiredOptionWasNotProvided not translatedForse già presa @JPBlanc l’ha presa 104 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
dotnet/command-line-api#2822 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
dotnet/command-line-api#2792 · 2 commenti · 15 reazioni ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
dotnet/command-line-api#2704 ·
-
GetCompletions should check exit code of invoked applicationForse già presa @baradgur l’ha presa 1275 giorni fa. ApertaArea-Completions bug help wanted
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
dotnet/command-line-api#2137 · 1 commento · 3 reazioni ·
Tutte le issue di dotnet/command-line-api
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
activescott/lessmsi#306 ·
-
Python: Bug: split_plaintext_paragraph / split_markdown_paragraph can return a chunk larger than max_tokensForse già presa @xThreeh l’ha presa oggi. Apertapython triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
microsoft/semantic-kernel#14566 ·
I maintainer di solito rispondono entro 4 giorni
-
triage
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
rjmurillo/moq.analyzers#1384 ·
-
Variables passed to Compensated are not set on the routing slipForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
MassTransit/MassTransit#6249 ·
-
security
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
Sendspin/sendspin-dotnet#339 ·
I maintainer di solito rispondono entro 1 giorno