Eccezione vs set di risultati vuoto quando gli input sono tecnicamente validi, ma insoddisfacenti

Sto sviluppando una libreria destinata al rilascio pubblico. Contiene vari metodi per operare su insiemi di oggetti: generare, ispezionare, partizionare e proiettare gli insiemi in nuove forme. Nel caso sia pertinente, è una libreria di classe C # contenente estensioni in stile LINQ su IEnumerable, da rilasciare come pacchetto NuGet.

Ad alcuni dei metodi in questa libreria possono essere forniti parametri di input non soddisfacenti. Ad esempio, nei metodi combinatori, esiste un metodo per generare tutti gli insiemi di n elementi che possono essere costruiti da un insieme di origine di m elementi. Ad esempio, dato il set:

1, 2, 3, 4, 5

e chiedere combinazioni di 2 produrrebbe:

1, 2
1, 3
1, 4
ecc ...
5, 3
5, 4

Ora, ovviamente, è possibile chiedere qualcosa che non può essere fatto, come dargli un set di 3 elementi e quindi chiedere combinazioni di 4 elementi mentre si imposta l'opzione che dice che può usare ogni oggetto solo una volta.

In questo scenario, ogni parametro è individualmente valido:

• La raccolta di origine non è nulla e contiene elementi
• La dimensione richiesta delle combinazioni è un numero intero diverso da zero
• La modalità richiesta (usa ogni elemento una sola volta) è una scelta valida

Tuttavia, lo stato dei parametri quando presi insieme causa problemi.

In questo scenario, ti aspetteresti che il metodo generi un'eccezione (ad es. InvalidOperationException) O restituisca una raccolta vuota? O mi sembra valido:

• Non è possibile produrre combinazioni di n elementi da un insieme di m elementi in cui n> m se è consentito utilizzare ogni articolo una sola volta, quindi questa operazione può essere considerata impossibile, quindi InvalidOperationException.
• L'insieme di combinazioni di dimensione n che possono essere prodotte da m articoli quando n> m è un insieme vuoto; nessuna combinazione può essere prodotta.

L'argomento per un set vuoto

La mia prima preoccupazione è che un'eccezione impedisce il concatenamento idiomatico di metodi in stile LINQ quando si ha a che fare con set di dati che potrebbero avere dimensioni sconosciute. In altre parole, potresti voler fare qualcosa del genere:

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

Se il set di input ha dimensioni variabili, il comportamento di questo codice è imprevedibile. Se .CombinationsOf()genera un'eccezione quando someInputSetha meno di 4 elementi, questo codice a volte fallirà in fase di esecuzione senza alcuni controlli preliminari. Nell'esempio sopra questo controllo è banale, ma se lo chiami a metà di una catena più lunga di LINQ, questo potrebbe diventare noioso. Se restituisce un set vuoto, resultsarà vuoto, di cui potresti essere perfettamente soddisfatto.

L'argomento per un'eccezione

La mia seconda preoccupazione è che la restituzione di un set vuoto potrebbe nascondere problemi: se stai chiamando questo metodo a metà di una catena di LINQ e restituisce silenziosamente un set vuoto, potresti riscontrare problemi alcuni passaggi in seguito, o ritrovarti con un vuoto set di risultati, e potrebbe non essere ovvio come sia accaduto dato che hai sicuramente avuto qualcosa nel set di input.

Cosa ti aspetteresti e qual è il tuo argomento?

Restituisce un set vuoto

Mi aspetterei un set vuoto perché:

Ci sono 0 combinazioni di 4 numeri dall'insieme di 3 quando posso usare ogni numero solo una volta

In caso di dubbi, chiedi a qualcun altro.

La funzione esempio ha uno molto simile in Python: itertools.combinations. Vediamo come funziona:

>>> 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))
[]

E mi sento perfettamente bene. Mi aspettavo un risultato che potessi ripetere e ne ho ottenuto uno.

Ma, ovviamente, se dovessi chiedere qualcosa di stupido:

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

Quindi direi che se tutti i tuoi parametri vengono convalidati ma il risultato è un set vuoto restituisci un set vuoto, non sei il solo a farlo.

Come detto da @Bakuriu nei commenti, questo è lo stesso anche per una SQLquery simile SELECT <columns> FROM <table> WHERE <conditions>. Finché <columns>, <table>, <conditions>sono ben formati formati e si riferiscono ai nomi esistenti, è possibile costruire un insieme di condizioni che escludono l'un l'altro. La query risultante non produrrebbe semplicemente righe invece di lanciare un InvalidConditionsError.

In parole povere:

• Se si verifica un errore, è necessario sollevare un'eccezione. Ciò può comportare il fare le cose a passi invece che in una singola chiamata concatenata per sapere esattamente dove si è verificato l'errore.
• Se non si verificano errori ma il set risultante è vuoto, non generare un'eccezione, restituire il set vuoto. Un set vuoto è un set valido.

Concordo con la risposta di Ewan ma voglio aggiungere un ragionamento specifico.

Hai a che fare con operazioni matematiche, quindi potrebbe essere un buon consiglio attenersi alle stesse definizioni matematiche. Da un punto di vista matematico il numero di r -set di un n- set (cioè nCr ) è ben definito per tutti r> n> = 0. È zero. Quindi restituire un set vuoto sarebbe il caso previsto dal punto di vista matematico.

Trovo un buon modo per determinare se usare un'eccezione, è immaginare le persone coinvolte nella transazione.

Prendendo il recupero del contenuto di un file come esempio:

1. Per favore, prendimi il contenuto del file, "non esiste.txt"

   un. "Ecco il contenuto: una raccolta vuota di personaggi"

   b. "Ehm, c'è un problema, quel file non esiste. Non so cosa fare!"

2. Per favore, prendimi il contenuto del file, "esiste ma è vuoto.txt"

   un. "Ecco il contenuto: una raccolta vuota di personaggi"

   b. "Ehm, c'è un problema, non c'è niente in questo file. Non so cosa fare!"

Non c'è dubbio che alcuni non saranno d'accordo, ma per la maggior parte delle persone, "Erm, c'è un problema" ha senso quando il file non esiste e restituisce "una raccolta vuota di caratteri" quando il file è vuoto.

Quindi applicando lo stesso approccio al tuo esempio:

3. Per favore, dammi tutte le combinazioni di 4 articoli per {1, 2, 3}

   un. Non ce ne sono, ecco un set vuoto.

   b. C'è un problema, non so cosa fare.

Ancora una volta, "C'è un problema" avrebbe senso se, ad esempio, nullvenisse offerto come set di articoli, ma "ecco un set vuoto" sembra una risposta ragionevole alla richiesta di cui sopra.

Se la restituzione di un valore vuoto maschera un problema (ad esempio un file mancante, a null), in genere dovrebbe essere utilizzata un'eccezione (a meno che la lingua scelta non supporti i option/maybetipi, a volte hanno più senso). Altrimenti, restituire un valore vuoto probabilmente semplificherà il costo e rispetta meglio il principio del minimo stupore.

Poiché è per una libreria di uso generale, il mio istinto sarebbe: Lascia che l'utente finale scelga.

Proprio come abbiamo Parse()e TryParse()disponibile per noi possiamo avere l'opzione di cui utilizziamo a seconda dell'output di cui abbiamo bisogno dalla funzione. Passeresti meno tempo a scrivere e mantenere un wrapper per le funzioni per lanciare l'eccezione piuttosto che discutere sulla scelta di una singola versione della funzione.

È necessario convalidare gli argomenti forniti quando viene chiamata la funzione. E di fatto, vuoi sapere come gestire argomenti non validi. Il fatto che più argomenti dipendano l'uno dall'altro, non compensa il fatto che si convalidano gli argomenti.

Vorrei quindi votare per ArgumentException fornendo le informazioni necessarie all'utente per capire cosa è andato storto.

Ad esempio, controlla la public static TSource ElementAt<TSource>(this IEnumerable<TSource>, Int32)funzione in Linq. Che genera un ArgumentOutOfRangeException se l'indice è inferiore a 0 o maggiore o uguale al numero di elementi nell'origine. Pertanto l'indice viene convalidato rispetto all'enumerabile fornito dal chiamante.

Dovresti eseguire una delle seguenti operazioni (sebbene continui a gettare costantemente problemi di base come un numero negativo di combinazioni):

1. Fornire due implementazioni, una che restituisce un set vuoto quando gli input insieme sono privi di senso e uno che genera. Prova a chiamarli CombinationsOfe CombinationsOfWithInputCheck. O qualunque cosa ti piaccia. È possibile invertire ciò in modo che quello di controllo input sia il nome più breve e quello elenco CombinationsOfAllowInconsistentParameters.

2. Per i metodi Linq, restituisci il vuoto IEnumerablenella premessa esatta che hai delineato. Quindi, aggiungi questi metodi Linq alla tua libreria:

   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;
         }
      }
   }

   Infine, usalo così:

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

   o in questo modo:

   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();

   Si noti che il metodo privato essendo diverso da quello pubblico è necessario affinché si verifichi il lancio o il comportamento dell'azione quando viene creata la catena linq anziché qualche tempo dopo quando viene elencata. Lo vuoi lanciare subito.

   Si noti, tuttavia, che ovviamente deve enumerare almeno il primo elemento per determinare se ci sono elementi. Questo è un potenziale svantaggio che penso sia in gran parte mitigato dal fatto che qualsiasi futuro spettatore può facilmente ragionare sul fatto che un ThrowIfEmptymetodo deve enumerare almeno un elemento, quindi non dovrebbe essere sorpreso dal farlo. Ma non lo sai mai. Potresti renderlo più esplicito ThrowIfEmptyByEnumeratingAndReEmittingFirstItem. Ma sembra un gigantesco eccessivo.

Penso che # 2 sia abbastanza, beh, fantastico! Ora il potere sta nel codice chiamante e il prossimo lettore del codice capirà esattamente cosa sta facendo e non dovrà affrontare eccezioni impreviste.

Vedo argomenti per entrambi i casi d'uso: un'eccezione è eccezionale se il codice downstream prevede set che contengono dati. D'altra parte, semplicemente un set vuoto è ottimo se questo è previsto.

Penso che dipenda dalle aspettative del chiamante se si tratta di un errore o di un risultato accettabile, quindi trasferirei la scelta al chiamante. Forse introdurre un'opzione?

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

Esistono due approcci per decidere se non esiste una risposta ovvia:

• Scrivi il codice assumendo prima un'opzione, poi l'altra. Considera quale funzionerebbe meglio nella pratica.

• Aggiungi un parametro booleano "rigoroso" per indicare se desideri che i parametri siano rigorosamente verificati o meno. Ad esempio, Java SimpleDateFormatha un setLenientmetodo per tentare di analizzare input che non corrispondono completamente al formato. Ovviamente, dovresti decidere qual è l'impostazione predefinita.

In base alla tua analisi, restituire l'insieme vuoto sembra chiaramente giusto: l'hai persino identificato come qualcosa che alcuni utenti potrebbero effettivamente desiderare e non sono caduti nella trappola di vietare un certo utilizzo perché non riesci a immaginare che gli utenti non vogliano mai usarlo quel modo.

Se ritieni davvero che alcuni utenti potrebbero voler forzare resi non vuoti, dai loro un modo per chiedere quel comportamento piuttosto che forzarlo su tutti. Ad esempio, potresti:

• Rendilo un'opzione di configurazione su qualunque oggetto stia eseguendo l'azione per l'utente.
• Trasformalo in una bandiera che l'utente può facoltativamente passare alla funzione.
• Fornire un AssertNonemptycontrollo che possono mettere nelle loro catene.
• Crea due funzioni, una che afferma non vuota e una che non lo fa.

Dipende molto da ciò che gli utenti si aspettano di ottenere. Per un esempio (in qualche modo non correlato) se il tuo codice esegue la divisione, puoi lanciare un'eccezione o restituire Info NaNquando dividi per zero. Né è giusto o sbagliato, tuttavia:

• se ritorni Infin una libreria Python, le persone ti assaliranno per nascondere errori
• se si genera un errore in una libreria Matlab, le persone ti assaliranno per non aver elaborato i dati con valori mancanti

Nel tuo caso, sceglierei la soluzione che sarà meno sorprendente per gli utenti finali. Dato che stai sviluppando una libreria che si occupa di set, un set vuoto sembra qualcosa che i tuoi utenti si aspetterebbero di gestire, quindi restituirlo sembra una cosa sensata da fare. Ma potrei sbagliarmi: hai una comprensione del contesto molto migliore di chiunque altro qui, quindi se ti aspetti che i tuoi utenti facciano affidamento sul fatto che il set non sia sempre vuoto, dovresti lanciare subito un'eccezione.

Le soluzioni che consentono all'utente di scegliere (come l'aggiunta di un parametro "rigoroso") non sono definitive, poiché sostituiscono la domanda originale con una nuova equivalente: "Quale valore di strictdovrebbe essere il valore predefinito?"

È una concezione comune (in matematica) che quando selezioni elementi su un set non riesci a trovare alcun elemento e quindi ottieni un set vuoto . Ovviamente devi essere coerente con la matematica se vai in questo modo:

Regole comuni stabilite:

• Set.Foreach (predicato); // restituisce sempre true per set vuoti
• Set.Exists (predicato); // restituisce sempre false per set vuoti

La tua domanda è molto sottile:

• Potrebbe essere che l'input della tua funzione debba rispettare un contratto : in tal caso qualsiasi input non valido dovrebbe sollevare un'eccezione, il gioco è fatto, la funzione non funziona con parametri regolari.

• Potrebbe essere che l'input della tua funzione debba comportarsi esattamente come un set e quindi dovrebbe essere in grado di restituire un set vuoto.

Ora se fossi in te andrei nel modo "Set", ma con un grande "MA".

Supponi di avere una raccolta che "per ipotesi" dovrebbe avere solo studentesse:

class FemaleClass{

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

Ora la tua collezione non è più un "insieme puro", perché hai un contratto e quindi dovresti far rispettare il tuo contratto con un'eccezione.

Quando usi le tue funzioni "set" in modo puro, non dovresti generare eccezioni in caso di set vuoto, ma se hai raccolte che non sono più "set puri", dovresti lanciare eccezioni dove appropriato .

Dovresti sempre fare ciò che sembra più naturale e coerente: per me un insieme dovrebbe aderire a regole stabilite, mentre le cose che non sono serie dovrebbero avere le loro regole ben pensate.

Nel tuo caso sembra una buona idea fare:

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;
}

Ma non è davvero una buona idea, ora abbiamo uno stato non valido che può verificarsi in fase di esecuzione in momenti casuali, tuttavia è implicito nel problema, quindi non possiamo rimuoverlo, sicuro che possiamo spostare l'eccezione all'interno di un metodo di utilità (è esattamente lo stesso codice, spostato in luoghi diversi), ma è sbagliato e in pratica la cosa migliore che puoi fare è attenersi alle normali regole stabilite .

Infatti l'aggiunta di nuova complessità solo per dimostrare che è possibile scrivere metodi di query linq non sembra utile per il tuo problema , sono abbastanza sicuro che se OP ci può dire di più sul suo dominio, probabilmente potremmo trovare il punto in cui l'eccezione è davvero necessaria (se affatto, è possibile che il problema non richieda alcuna eccezione).