Excepción vs conjunto de resultados vacío cuando las entradas son técnicamente válidas, pero insatisfactorias

Estoy desarrollando una biblioteca destinada al lanzamiento público. Contiene varios métodos para operar en conjuntos de objetos: generar, inspeccionar, particionar y proyectar los conjuntos en nuevas formas. En caso de que sea relevante, es una biblioteca de clase C # que contiene extensiones de estilo LINQ IEnumerable, que se lanzará como un paquete NuGet.

Algunos de los métodos en esta biblioteca pueden recibir parámetros de entrada insatisfactorios. Por ejemplo, en los métodos combinatorios, hay un método para generar todos los conjuntos de n elementos que se pueden construir a partir de un conjunto fuente de m elementos. Por ejemplo, dado el conjunto:

1, 2, 3, 4, 5

y pedir combinaciones de 2 produciría:

1, 2
1, 3
1, 4,
etc ...
5, 3
5, 4

Ahora, obviamente es posible pedir algo que no se puede hacer, como darle un conjunto de 3 elementos y luego pedir combinaciones de 4 elementos mientras configura la opción que dice que solo puede usar cada elemento una vez.

En este escenario, cada parámetro es válido individualmente :

• La colección de origen no es nula y contiene elementos.
• El tamaño solicitado de las combinaciones es un entero positivo distinto de cero
• El modo solicitado (use cada elemento solo una vez) es una opción válida

Sin embargo, el estado de los parámetros cuando se toman juntos causa problemas.

En este escenario, ¿esperaría que el método arroje una excepción (por ejemplo InvalidOperationException) o devuelva una colección vacía? Cualquiera de los dos me parece válido:

• No puede producir combinaciones de n elementos a partir de un conjunto de m elementos donde n> m si solo se le permite usar cada elemento una vez, por lo tanto, esta operación puede considerarse imposible InvalidOperationException.
• El conjunto de combinaciones de tamaño n que se pueden producir a partir de m elementos cuando n> m es un conjunto vacío; No se pueden producir combinaciones.

El argumento para un conjunto vacío

Mi primera preocupación es que una excepción evita el encadenamiento idiomático de métodos al estilo LINQ cuando se trata de conjuntos de datos que pueden tener un tamaño desconocido. En otras palabras, es posible que desee hacer algo como esto:

var result = someInputSet
    .CombinationsOf(4, CombinationsGenerationMode.Distinct)
    .Select(combo => /* do some operation to a combination */)
    .ToList();

Si su conjunto de entrada es de tamaño variable, el comportamiento de este código es impredecible. Si .CombinationsOf()arroja una excepción cuando someInputSettiene menos de 4 elementos, este código a veces fallará en tiempo de ejecución sin alguna verificación previa. En el ejemplo anterior, esta comprobación es trivial, pero si la está llamando a la mitad de una cadena más larga de LINQ, esto puede ser tedioso. Si devuelve un conjunto vacío, entonces resultestará vacío, con lo que puede estar perfectamente satisfecho.

El argumento para una excepción

Mi segunda preocupación es que devolver un conjunto vacío puede ocultar problemas: si está llamando a este método a la mitad de una cadena de LINQ y devuelve silenciosamente un conjunto vacío, entonces puede tener problemas algunos pasos más tarde o encontrarse con un vacío conjunto de resultados, y puede no ser obvio cómo sucedió eso dado que definitivamente tenía algo en el conjunto de entrada.

¿Qué esperarías y cuál es tu argumento?

Devolver un conjunto vacío

Esperaría un conjunto vacío porque:

Hay 0 combinaciones de 4 números del conjunto de 3 cuando solo puedo usar cada número una vez

En caso de duda, pregunte a alguien más.

Su función ejemplo tiene una muy similar en Python: itertools.combinations. Vamos a ver cómo funciona:

>>> import itertools
>>> input = [1, 2, 3, 4, 5]
>>> list(itertools.combinations(input, 2))
[(1, 2), (1, 3), (1, 4), (1, 5), (2, 3), (2, 4), (2, 5), (3, 4), (3, 5), (4, 5)]
>>> list(itertools.combinations(input, 5))
[(1, 2, 3, 4, 5)]
>>> list(itertools.combinations(input, 6))
[]

Y se siente perfectamente bien para mí. Esperaba un resultado que pudiera repetir y obtuve uno.

Pero, obviamente, si fueras a preguntar algo estúpido:

>>> list(itertools.combinations(input, -1))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: r must be non-negative

Entonces, diría que si todos sus parámetros se validan pero el resultado es un conjunto vacío, devuelve un conjunto vacío, no es el único que lo hace.

Como dijo @Bakuriu en los comentarios, esto también es lo mismo para una SQLconsulta como SELECT <columns> FROM <table> WHERE <conditions>. Mientras <columns>, <table>, <conditions>así se forman en forma y se refieren a los nombres existentes, se puede construir un conjunto de condiciones que se excluyen mutuamente. La consulta resultante simplemente no generaría filas en lugar de arrojar un InvalidConditionsError.

En términos simples:

• Si hay un error, debe plantear una excepción. Eso puede implicar hacer cosas en pasos en lugar de en una sola llamada encadenada para saber exactamente dónde ocurrió el error.
• Si no hay ningún error pero el conjunto resultante está vacío, no genere una excepción, devuelva el conjunto vacío. Un conjunto vacío es un conjunto válido.

Estoy de acuerdo con la respuesta de Ewan, pero quiero agregar un razonamiento específico.

Se trata de operaciones matemáticas, por lo que podría ser un buen consejo seguir con las mismas definiciones matemáticas. Desde un punto de vista matemático, el número de conjuntos r de un conjunto n (es decir, nCr ) está bien definido para todos r> n> = 0. Es cero. Por lo tanto, devolver un conjunto vacío sería el caso esperado desde un punto de vista matemático.

Encuentro una buena manera de determinar si se usa una excepción, es imaginar a las personas involucradas en la transacción.

Tomando la recuperación del contenido de un archivo como ejemplo:

1. Por favor, tráeme el contenido del archivo, "no existe.txt"

   a. "Aquí está el contenido: una colección vacía de personajes"

   si. "Erm, hay un problema, ese archivo no existe. ¡No sé qué hacer!"

2. Por favor, tráeme el contenido del archivo, "existe pero está vacío.

   a. "Aquí está el contenido: una colección vacía de personajes"

   si. "Erm, hay un problema, no hay nada en este archivo. ¡No sé qué hacer!"

Sin duda, algunos estarán en desacuerdo, pero para la mayoría de la gente, "Erm, hay un problema" tiene sentido cuando el archivo no existe y devuelve "una colección vacía de caracteres" cuando el archivo está vacío.

Entonces, aplicando el mismo enfoque a tu ejemplo:

3. Por favor, dame todas las combinaciones de 4 artículos para {1, 2, 3}

   a. No hay ninguno, aquí hay un conjunto vacío.

   si. Hay un problema, no sé qué hacer.

Una vez más, "Hay un problema" tendría sentido si, por ejemplo, nullse ofrecieran como el conjunto de elementos, pero "aquí hay un conjunto vacío" parece una respuesta sensata a la solicitud anterior.

Si devolver un valor vacío enmascara un problema (por ejemplo, un archivo faltante, a null), generalmente se debe usar una excepción en su lugar (a menos que el idioma elegido admita option/maybetipos, a veces tienen más sentido). De lo contrario, devolver un valor vacío probablemente simplificará el costo y cumplirá mejor con el principio del mínimo asombro.

Como es para una biblioteca de propósito general, mi instinto sería Dejar que el usuario final elija.

Al igual que tenemos Parse()y tenemos TryParse()a nuestra disposición, podemos tener la opción de utilizar según la salida que necesitemos de la función. Pasaría menos tiempo escribiendo y manteniendo un contenedor de funciones para lanzar la excepción que discutiendo sobre la elección de una versión única de la función.

Debe validar los argumentos proporcionados cuando se llama a su función. Y, de hecho, desea saber cómo manejar argumentos no válidos. El hecho de que varios argumentos dependan unos de otros, no compensa el hecho de que valides los argumentos.

Por lo tanto, votaría por la excepción ArgumentException que proporciona la información necesaria para que el usuario comprenda qué salió mal.

Como ejemplo, verifique la public static TSource ElementAt<TSource>(this IEnumerable<TSource>, Int32)función en Linq. Lo que arroja una ArgumentOutOfRangeException si el índice es menor que 0 o mayor o igual que el número de elementos en la fuente. Por lo tanto, el índice se valida con respecto a los enumerables proporcionados por la persona que llama.

Debe hacer uno de los siguientes (aunque continúe lanzando constantemente problemas básicos como un número negativo de combinaciones):

1. Proporcione dos implementaciones, una que devuelva un conjunto vacío cuando las entradas juntas no tengan sentido y otra que arroje. Intenta llamarlos CombinationsOfy CombinationsOfWithInputCheck. O lo que quieras. Puede revertir esto para que el que verifique la entrada sea el nombre más corto y el de la lista CombinationsOfAllowInconsistentParameters.

2. Para los métodos de Linq, devuelva el vacío IEnumerableen la premisa exacta que ha esbozado. Luego, agregue estos métodos de Linq a su biblioteca:

   public static class EnumerableExtensions {
      public static IEnumerable<T> ThrowIfEmpty<T>(this IEnumerable<T> input) {
         return input.IfEmpty<T>(() => {
            throw new InvalidOperationException("An enumerable was unexpectedly empty");
         });
      }
   
      public static IEnumerable<T> IfEmpty<T>(
         this IEnumerable<T> input,
         Action callbackIfEmpty
      ) {
         var enumerator = input.GetEnumerator();
         if (!enumerator.MoveNext()) {
            // Safe because if this throws, we'll never run the return statement below
            callbackIfEmpty();
         }
         return EnumeratePrimedEnumerator(enumerator);
      }
   
      private static IEnumerable<T> EnumeratePrimedEnumerator<T>(
         IEnumerator<T> primedEnumerator
      ) {
         yield return primedEnumerator.Current;
         while (primedEnumerator.MoveNext()) {
            yield return primedEnumerator.Current;
         }
      }
   }

   Finalmente, use eso así:

   var result = someInputSet
      .CombinationsOf(4, CombinationsGenerationMode.Distinct)
      .ThrowIfEmpty()
      .Select(combo => /* do some operation to a combination */)
      .ToList();

   o así:

   var result = someInputSet
      .CombinationsOf(4, CombinationsGenerationMode.Distinct)
      .IfEmpty(() => _log.Warning(
         $@"Unexpectedly received no results when creating combinations for {
            nameof(someInputSet)}"
      ))
      .Select(combo => /* do some operation to a combination */)
      .ToList();

   Tenga en cuenta que se requiere que el método privado sea diferente del público para que se produzca el comportamiento de lanzamiento o acción cuando se crea la cadena linq en lugar de algún tiempo después cuando se enumera. Usted quiere que tirar de inmediato.

   Sin embargo, tenga en cuenta que, por supuesto, tiene que enumerar al menos el primer elemento para determinar si hay algún elemento. Este es un inconveniente potencial que creo que se ve mitigado principalmente por el hecho de que cualquier futuro espectador puede razonar fácilmente que un ThrowIfEmptymétodo tiene que enumerar al menos un elemento, por lo que no debería sorprenderse al hacerlo. Pero nunca se sabe. Podrías hacer esto más explícito ThrowIfEmptyByEnumeratingAndReEmittingFirstItem. Pero eso parece una exageración gigantesca.

¡Creo que el # 2 es bastante bueno! Ahora el poder está en el código de llamada, y el próximo lector del código comprenderá exactamente lo que está haciendo, y no tendrá que lidiar con excepciones inesperadas.

Puedo ver argumentos para ambos casos de uso: una excepción es excelente si el código descendente espera conjuntos que contienen datos. Por otro lado, simplemente un conjunto vacío es genial si se espera esto.

Creo que depende de las expectativas de la persona que llama si se trata de un error o un resultado aceptable, por lo que transferiría la elección a la persona que llama. Tal vez introducir una opción?

.CombinationsOf(4, CombinationsGenerationMode.Distinct, Options.AllowEmptySets)

Hay dos enfoques para decidir si no hay una respuesta obvia:

• Escriba el código asumiendo primero una opción, luego la otra. Considere cuál funcionaría mejor en la práctica.

• Agregue un parámetro booleano "estricto" para indicar si desea que los parámetros se verifiquen estrictamente o no. Por ejemplo, Java SimpleDateFormattiene un setLenientmétodo para intentar analizar entradas que no coinciden completamente con el formato. Por supuesto, tendría que decidir cuál es el valor predeterminado.

Según su propio análisis, devolver el conjunto vacío parece claramente correcto: incluso lo ha identificado como algo que algunos usuarios realmente desean y no ha caído en la trampa de prohibir algún uso porque no puede imaginar que los usuarios quieran usarlo alguna vez. de esa manera.

Si realmente crees que algunos usuarios pueden querer forzar retornos no vacíos, entonces dales una forma de pedir ese comportamiento en lugar de forzarlo a todos. Por ejemplo, podrías:

• Conviértalo en una opción de configuración en cualquier objeto que esté realizando la acción para el usuario.
• Conviértalo en una bandera que el usuario pueda pasar opcionalmente a la función.
• Proporcione un AssertNonemptycheque que puedan poner en sus cadenas.
• Haga dos funciones, una que afirme que no está vacía y otra que no.

Realmente depende de lo que sus usuarios esperan obtener. Por ejemplo (un poco no relacionado) si su código realiza la división, puede lanzar una excepción o retorno Info NaNcuando divide por cero. Sin embargo, ninguno de los dos es correcto o incorrecto:

• Si regresas Infa una biblioteca de Python, la gente te atacará por esconder errores
• Si genera un error en una biblioteca de Matlab, las personas lo atacarán por no procesar los datos con valores faltantes.

En su caso, elegiría la solución que será menos sorprendente para los usuarios finales. Como está desarrollando una biblioteca que se ocupa de conjuntos, un conjunto vacío parece algo con lo que sus usuarios esperarían lidiar, por lo que devolverlo parece algo sensato. Pero puedo estar equivocado: tiene una comprensión mucho mejor del contexto que cualquier otra persona aquí, por lo que si espera que sus usuarios confíen en que el conjunto no siempre esté vacío, debe lanzar una excepción de inmediato.

Las soluciones que permiten al usuario elegir (como agregar un parámetro "estricto") no son definitivas, ya que reemplazan la pregunta original por una nueva equivalente: "¿Qué valor de strictdebería ser el predeterminado?"

Es una concepción común (en matemáticas) que cuando selecciona elementos sobre un conjunto, no puede encontrar ningún elemento y, por lo tanto, obtiene un conjunto vacío . Por supuesto, debe ser coherente con las matemáticas si sigue este camino:

Reglas comunes establecidas:

• Set.Foreach (predicado); // siempre devuelve verdadero para conjuntos vacíos
• Set.Exists (predicado); // siempre devuelve falso para conjuntos vacíos

Tu pregunta es muy sutil:

• Podría ser que la entrada de su función tenga que respetar un contrato : en ese caso, cualquier entrada no válida debería generar una excepción, eso es todo, la función no funciona bajo parámetros regulares.

• Podría ser que la entrada de su función tenga que comportarse exactamente como un conjunto y, por lo tanto, debería poder devolver un conjunto vacío.

Ahora, si estuviera dentro de ti, iría al modo "Set", pero con un gran "PERO".

Suponga que tiene una colección que "por hipotesis" debería tener solo alumnas:

class FemaleClass{

    FemaleStudent GetAnyFemale(){
        var femaleSet= mySet.Select( x=> x.IsFemale());
        if(femaleSet.IsEmpty())
            throw new Exception("No female students");
        else
            return femaleSet.Any();
    }
}

Ahora su colección ya no es un "conjunto puro", porque tiene un contrato y, por lo tanto, debe hacer cumplir su contrato con una excepción.

Cuando utiliza sus funciones de "conjunto" de una manera pura, no debe lanzar excepciones en el caso de un conjunto vacío, pero si tiene colecciones que ya no son "conjuntos puros", entonces debe lanzar excepciones cuando sea apropiado .

Siempre debe hacer lo que se siente más natural y consistente: para mí, un conjunto debe adherirse a las reglas establecidas, mientras que las cosas que no son conjuntos deben tener sus reglas correctamente pensadas.

En su caso, parece una buena idea hacer:

List SomeMethod( Set someInputSet){
    var result = someInputSet
        .CombinationsOf(4, CombinationsGenerationMode.Distinct)
        .Select(combo => /* do some operation to a combination */)
        .ToList();

    // the only information here is that set is empty => there are no combinations

    // BEWARE! if 0 here it may be invalid input, but also a empty set
    if(result.Count == 0)  //Add: "&&someInputSet.NotEmpty()"

    // we go a step further, our API require combinations, so
    // this method cannot satisfy the API request, then we throw.
         throw new Exception("you requsted impossible combinations");

    return result;
}

Pero no es realmente una buena idea, ahora tenemos un estado no válido que puede ocurrir en tiempo de ejecución en momentos aleatorios, sin embargo, eso está implícito en el problema, por lo que no podemos eliminarlo, seguro que podemos mover la excepción dentro de algún método de utilidad (es exactamente el mismo código, movido en diferentes lugares), pero eso está mal y básicamente lo mejor que puedes hacer es seguir las reglas establecidas .

De hecho, agregar nueva complejidad solo para mostrar que puede escribir métodos de consultas linq parece no valer para su problema , estoy bastante seguro de que si OP puede decirnos más sobre su dominio, probablemente podríamos encontrar el lugar donde realmente se necesita la excepción (si en absoluto, es posible que el problema no requiera ninguna excepción).