Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
#2,841 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
csharp
Área
cli

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

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dotnet/command-line-api

Todos los issues de dotnet/command-line-api

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.