Sollte ich leere Sammlungen in meinen Methoden akzeptieren, die über sie iterieren?

Ich habe eine Methode, bei der die gesamte Logik in einer foreach-Schleife ausgeführt wird, die den Parameter der Methode durchläuft:

public IEnumerable<TransformedNode> TransformNodes(IEnumerable<Node> nodes)
{
    foreach(var node in nodes)
    {
        // yadda yadda yadda
        yield return transformedNode;
    }
}

In diesem Fall führt das Einreichen einer leeren Sammlung zu einer leeren Sammlung, aber ich frage mich, ob das nicht klug ist.

Meine Logik hier ist, dass, wenn jemand diese Methode aufruft, er beabsichtigt, Daten weiterzuleiten, und nur unter irrtümlichen Umständen eine leere Auflistung an meine Methode übergeben würde.

Sollte ich dieses Verhalten abfangen und eine Ausnahme auslösen, oder ist es empfehlenswert, die leere Auflistung zurückzugeben?

Dienstprogrammmethoden sollten keine leeren Sammlungen verwenden. Ihre API-Kunden würden Sie dafür hassen.

Eine Sammlung kann leer sein. Eine "Sammlung, die nicht leer sein darf" ist konzeptionell viel schwieriger zu bearbeiten.

Das Transformieren einer leeren Sammlung hat ein offensichtliches Ergebnis: die leere Sammlung. (Sie können sogar etwas Müll sparen, indem Sie den Parameter selbst zurückgeben.)

Es gibt viele Umstände, unter denen ein Modul Listen von Dingen führt, die möglicherweise bereits mit etwas gefüllt sind oder nicht. Vor jedem Anruf auf Leere prüfen zu müssen, transformist ärgerlich und kann dazu führen, dass ein einfacher, eleganter Algorithmus zu einem hässlichen Durcheinander wird.

Utility-Methoden sollten immer danach streben, in ihren Eingaben liberal und in ihren Ausgaben konservativ zu sein.

Gehen Sie aus all diesen Gründen, um Himmels willen, korrekt mit der leeren Sammlung um. Nichts ist ärgerlicher als ein Hilfsmodul, das denkt, es weiß, was Sie wollen, besser als Sie.

Ich sehe zwei wichtige Fragen, die die Antwort darauf bestimmen:

1. Kann Ihre Funktion irgendetwas Sinnvolles und Logisches zurückgeben, wenn eine leere Sammlung (einschließlich Null ) übergeben wird?
2. Was ist der allgemeine Programmierstil in dieser Anwendung / Bibliothek / Team? (Insbesondere, wie FP sind Sie?)

1. Sinnvolle Rendite

Wenn Sie etwas Sinnvolles zurückgeben können, geben Sie im Wesentlichen keine Ausnahme aus. Lassen Sie den Anrufer mit dem Ergebnis umgehen. Also, wenn Ihre Funktion ...

• Zählt die Anzahl der Elemente in der Auflistung und gibt 0 zurück. Das war einfach.
• Sucht nach Elementen, die bestimmten Kriterien entsprechen, und gibt eine leere Sammlung zurück. Bitte werfen Sie nichts. Der Anrufer verfügt möglicherweise über eine große Sammlung von Sammlungen, von denen einige leer sind, andere nicht. Der Aufrufer möchte alle übereinstimmenden Elemente in einer Sammlung haben. Ausnahmen machen dem Anrufer nur das Leben schwerer.
• Sucht nach den größten / kleinsten / am besten zu den Kriterien in der Liste passenden. Hoppla. Abhängig von der Frage nach dem Stil können Sie hier eine Ausnahme auslösen oder null zurückgeben . Ich hasse null (sehr viel eine FP-Person), aber es ist hier wohl sinnvoller und Sie können Ausnahmen für unerwartete Fehler in Ihrem eigenen Code reservieren. Wenn der Anrufer nicht auf null prüft, kommt es trotzdem zu einer ziemlich eindeutigen Ausnahme. Aber das überlässt du ihnen.
• Fragt nach dem n-ten Element in der Sammlung oder den ersten / letzten n Elementen. Dies ist der beste Fall für eine Ausnahme und der, der den Anrufer am wenigsten verwirrt und erschwert. Es kann immer noch ein Fall für null gemacht werden, wenn Sie und Ihr Team es gewohnt sind, dies aus allen im vorherigen Punkt genannten Gründen zu überprüfen. Dies ist jedoch der bisher gültigste Fall, um eine DudeYou Know YouShouldCheckTheSizeFirst- Ausnahme auszulösen . Wenn Ihr Stil funktionaler ist, dann entweder null oder lesen Sie meine Antwort auf Stil weiter .

Im Allgemeinen sagt mir mein FP-Bias "etwas Sinnvolles zurückgeben" und Null kann in diesem Fall eine gültige Bedeutung haben.

2. Stil

Befürwortet Ihr allgemeiner Code (oder der Code des Projekts oder des Teams) einen funktionalen Stil? Wenn nein, werden Ausnahmen erwartet und behandelt. Wenn ja, können Sie einen Optionstyp zurückgeben . Bei einem Optionstyp geben Sie entweder eine aussagekräftige Antwort oder None / Nothing zurück . In meinem dritten Beispiel von oben wäre Nichts eine gute Antwort im FP-Stil. Die Tatsache, dass die Funktion einen Optionstyp zurückgibt, signalisiert dem Anrufer möglicherweise eindeutig, dass es sich um eine aussagekräftige Antwort handelt, und dass der Anrufer darauf vorbereitet sein sollte, damit umzugehen. Ich glaube, es gibt dem Anrufer mehr Möglichkeiten (wenn Sie das Wortspiel verzeihen).

F # ist , wo alle kühlen .Net Kinder diese Art der Sache zu tun , aber C # tut unterstützen diesen Stil.

tl; dr

Bewahren Sie Ausnahmen für unerwartete Fehler in Ihrem eigenen Codepfad auf, nicht vollständig vorhersehbare (und zulässige) Eingaben von Dritten.

Wie immer kommt es darauf an.

Ist es wichtig, dass die Sammlung leer ist?
Der meiste Code für die Sammlung würde wahrscheinlich "nein" sagen. Eine Sammlung kann eine beliebige Anzahl von Elementen enthalten, einschließlich Null.

Wenn Sie eine Art Sammlung haben, in der es "ungültig" ist, keine Elemente darin zu haben, dann ist dies eine neue Anforderung, und Sie müssen entscheiden, was Sie dagegen tun möchten.

Leihen Sie sich eine Testlogik aus der Datenbankwelt aus: Prüfen Sie , ob keine , eine und zwei Elemente vorhanden sind. Dies ist für die wichtigsten Fälle geeignet (Herauslösen schlecht geformter innerer oder kartesischer Verbindungsbedingungen).

Akzeptieren Sie im Hinblick auf ein gutes Design so viele Variationen in Ihren Eingaben wie möglich. Ausnahmen sollten nur ausgelöst werden, wenn (bei der Verarbeitung werden nicht akzeptable Eingaben angezeigt ODER es treten unerwartete Fehler auf) UND das Programm daher nicht vorhersehbar fortgesetzt werden kann .

In diesem Fall ist zu erwarten, dass eine leere Auflistung angezeigt wird und Ihr Code damit umgehen muss (was er bereits tut). Es wäre eine Verletzung von allem, was gut ist, wenn Ihr Code hier eine Ausnahme auslösen würde. Dies wäre vergleichbar mit dem Multiplizieren von 0 mit 0 in der Mathematik. Es ist überflüssig, aber absolut notwendig, damit es so funktioniert, wie es funktioniert.

Nun zum Argument der Nullsammlung. In diesem Fall ist eine Nullsammlung ein Programmierfehler: Der Programmierer hat vergessen, eine Variable zuzuweisen. Dies ist ein Fall, in dem eine Ausnahme ausgelöst werden kann, da Sie diese nicht sinnvoll in eine Ausgabe verarbeiten können. Wenn Sie dies versuchen, tritt ein unerwartetes Verhalten auf. Dies wäre in der Mathematik gleichbedeutend mit einer Division durch Null - es ist völlig bedeutungslos.

Die richtige Lösung ist viel schwieriger zu erkennen, wenn Sie Ihre Funktion nur isoliert betrachten. Betrachten Sie Ihre Funktion als Teil eines größeren Problems . Eine mögliche Lösung für dieses Beispiel sieht folgendermaßen aus (in Scala):

input.split("\\D")
.filterNot (_.isEmpty)
.map (_.toInt)
.filter (x => x >= 1000 && x <= 9999)

Zuerst teilen Sie die Zeichenfolge nach Nicht-Ziffern auf, filtern die leeren Zeichenfolgen heraus, konvertieren die Zeichenfolgen in Ganzzahlen und filtern dann, um nur die vierstelligen Zahlen beizubehalten. Ihre Funktion könnte die map (_.toInt)in der Pipeline sein.

Dieser Code ist ziemlich einfach, da jede Phase in der Pipeline nur eine leere Zeichenfolge oder eine leere Auflistung verarbeitet. Wenn Sie am Anfang eine leere Zeichenfolge eingeben, wird am Ende eine leere Liste ausgegeben. Sie müssen nicht nullnach jedem Anruf anhalten und nach einer Ausnahme suchen.

Dies setzt natürlich voraus, dass eine leere Ausgabeliste nicht mehr als eine Bedeutung hat. Wenn Sie zwischen einer leeren Ausgabe, die durch eine leere Eingabe verursacht wird, und einer durch die Transformation selbst verursachten Ausgabe unterscheiden müssen , ändert sich das grundlegend.

Bei dieser Frage handelt es sich eigentlich um Ausnahmen. Wenn Sie dies so betrachten und die leere Auflistung als Implementierungsdetail ignorieren, ist die Antwort einfach:

1) Eine Methode sollte eine Ausnahme auslösen, wenn sie nicht fortfahren kann: entweder die angegebene Aufgabe nicht ausführen oder den entsprechenden Wert zurückgeben.

2) Eine Methode sollte eine Ausnahme abfangen, wenn sie trotz des Fehlers fortfahren kann.

Daher sollte Ihre Hilfsmethode nicht "hilfreich" sein und eine Ausnahme auslösen, es sei denn, sie kann ihre Aufgabe nicht mit einer leeren Auflistung erledigen. Lassen Sie den Anrufer bestimmen, ob die Ergebnisse verarbeitet werden können.

Ob es eine leere Sammlung oder null zurückgibt, ist ein bisschen schwieriger, aber nicht viel: nullfähige Sammlungen sollten nach Möglichkeit vermieden werden. Der Zweck einer nullfähigen Auflistung besteht darin, (wie in SQL) anzugeben, dass Sie nicht über die Informationen verfügen. Eine Auflistung von untergeordneten Elementen kann beispielsweise null sein, wenn Sie nicht wissen, ob eine andere vorhanden ist, dies jedoch nicht wissen, dass sie es nicht tun. Aber wenn das aus irgendeinem Grund wichtig ist, ist es wahrscheinlich eine zusätzliche Variable wert, um es zu verfolgen.

Die Methode heißt TransformNodes. Im Falle einer leeren Sammlung als Eingabe ist es natürlich und intuitiv, eine leere Sammlung zurückzugewinnen, und dies ist mathematisch sinnvoll.

Wenn die Methode so benannt Maxund entworfen wurde, dass sie das maximale Element zurückgibt, wäre es natürlich, NoSuchElementExceptioneine leere Auflistung zu verwenden, da das Maximum von nichts keinen mathematischen Sinn ergibt.

Wenn die Methode so benannt JoinSqlColumnNamesund entworfen wurde, dass sie eine Zeichenfolge zurückgibt, bei der die Elemente durch ein Komma verbunden sind, um sie in SQL-Abfragen zu verwenden, wäre es sinnvoll, IllegalArgumentExceptioneine leere Auflistung zu verwenden, da der Aufrufer schließlich ohnehin einen SQL-Fehler erhalten würde, wenn er sie verwendet die Zeichenfolge in einer SQL-Abfrage direkt ohne weitere Überprüfungen, und anstatt auf eine zurückgegebene leere Zeichenfolge zu prüfen, hätte er stattdessen wirklich auf leere Auflistung prüfen müssen.

Lassen Sie uns einen Schritt zurücktreten und ein anderes Beispiel verwenden, das das arithmetische Mittel eines Array von Werten berechnet.

Wenn das Eingabearray leer (oder null) ist, können Sie die Anforderung des Aufrufers vernünftigerweise erfüllen? Nein. Welche Möglichkeiten haben Sie? Nun, Sie könnten:

• präsentieren / zurückgeben / einen Fehler werfen. Verwenden Sie die Konvention Ihrer Codebasis für diese Fehlerklasse.
• dokumentieren, dass ein Wert wie Null zurückgegeben wird
• dokumentieren, dass ein bestimmter ungültiger Wert zurückgegeben wird (zB NaN)
• dokumentieren, dass ein magischer Wert zurückgegeben wird (z. B. ein min oder max für den Typ oder ein hoffentlich indikativer Wert)
• Deklarieren Sie, dass das Ergebnis nicht angegeben ist
• erklären, dass die Aktion undefiniert ist
• usw.

Ich sage, gib ihnen den Fehler, wenn sie dir eine ungültige Eingabe gegeben haben und die Anfrage nicht abgeschlossen werden kann. Ich meine einen schweren Fehler vom ersten Tag an, damit sie die Anforderungen Ihres Programms verstehen. Schließlich ist Ihre Funktion nicht in der Lage zu reagieren. Wenn die Operation fehlschlagen könnte (z. B. Kopieren einer Datei), sollte Ihre API einen Fehler melden, mit dem sie umgehen kann.

Auf diese Weise können Sie festlegen, wie Ihre Bibliothek fehlerhafte und möglicherweise fehlgeschlagene Anforderungen behandelt.

Es ist sehr wichtig, dass Ihr Code konsistent mit diesen Fehlerklassen umgeht.

In der nächsten Kategorie legen Sie fest, wie Ihre Bibliothek mit Unsinnanforderungen umgeht. Kommen wir zurück auf ein Beispiel ähnlich wie bei Ihnen - wir verwenden , um eine Funktion , die bestimmt , ob eine Datei auf einem Pfad vorhanden ist : bool FileExistsAtPath(String). Wie gehen Sie mit diesem Szenario um, wenn der Client eine leere Zeichenfolge übergibt? Wie wäre es mit einem leeren oder einem Null-Array, an das übergeben wird void SaveDocuments(Array<Document>)? Entscheiden Sie sich für Ihre Bibliothek / Codebasis und seien Sie konsistent. Ich betrachte diese Fälle zufällig als Fehler und verbiete Kunden, unsinnige Anfragen zu stellen, indem ich sie (über eine Behauptung) als Fehler markiere. Einige Leute werden sich dieser Idee / Aktion stark widersetzen. Ich finde diese Fehlererkennung sehr hilfreich. Es ist sehr gut, um Probleme in Programmen zu lokalisieren - mit einer guten Lokalisierung des betreffenden Programms. Programme sind viel klarer und korrekter (unter Berücksichtigung der Weiterentwicklung Ihrer Codebasis) und brennen keine Zyklen innerhalb von Funktionen, die nichts bewirken. Auf diese Weise wird der Code kleiner / sauberer, und die Überprüfungen werden im Allgemeinen an die Stellen verschoben, an denen das Problem möglicherweise auftritt.

Als Faustregel gilt, dass eine Standardfunktion in der Lage sein sollte, die breiteste Liste von Eingaben zu akzeptieren und Feedback zu geben. Es gibt viele Beispiele, in denen Programmierer Funktionen auf eine Weise verwenden, die der Designer nicht geplant hatte. Aus diesem Grund glaube ich an die Funktion Sie sollten nicht nur leere Sammlungen, sondern eine Vielzahl von Eingabetypen akzeptieren und ordnungsgemäß Feedback geben können, auch wenn es sich um ein Fehlerobjekt handelt, das von einer beliebigen Operation an der Eingabe ausgeführt wurde.