Command validators don't seem to use the default value factory of an Option
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 52/100
Línea de trabajo
Comienza rastreando cómo los Validators a nivel de comando usan result.GetValue(_multiplier) y cómo se aplica el DefaultValueFactory de una Option. Compara ese comportamiento con los validadores a nivel de opción y GetValueOrDefault(); al hacerlo, queda establecida la gestión prevista de las opciones omitidas y la discrepancia observada queda cubierta por el comportamiento de validación relevante.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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?
- Lenguaje dominante
- C#
- Estrellas
- 3.7k
- Forks
- 432
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de dotnet/command-line-api
-
German localization is incompletePosiblemente ocupada @b-v-d-e-v la tomó hace 6 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
dotnet/command-line-api#2852 ·
-
Incomplete French (fr) translation: RequiredOptionWasNotProvided not translatedPosiblemente ocupada @JPBlanc la tomó hace 103 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
dotnet/command-line-api#2822 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
dotnet/command-line-api#2792 · 2 comentarios · 15 reacciones ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
dotnet/command-line-api#2704 ·
-
GetCompletions should check exit code of invoked applicationPosiblemente ocupada @baradgur la tomó hace 1275 días. AbiertoArea-Completions bug help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
dotnet/command-line-api#2137 · 1 comentario · 3 reacciones ·
Todos los issues de dotnet/command-line-api
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
owasp-dep-scan/dosai#79 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
pyrevitlabs/pyRevit#3730 ·
Los mantenedores suelen responder en 1 día
-
bug component/other
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
umbraco/Umbraco.AI#511 ·
Los mantenedores suelen responder en 1 día
-
sev:L
Dificultad 1/5 Menos de una hora Aptitud para principiantes 72/100
Systemorph/MeshWeaver#6233 ·
Los mantenedores suelen responder en 1 día
-
[Bug]:Abiertobug needs response
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Adyen/adyen-dotnet-api-library#1874 ·
Los mantenedores suelen responder en 1 día