it-swarm-eu.dev

Ist es besser, NULL oder leere Werte von Funktionen / Methoden zurückzugeben, bei denen der Rückgabewert nicht vorhanden ist?

Ich suche hier eine Empfehlung. Ich habe Probleme damit, ob es besser ist, NULL oder einen leeren Wert von einer Methode zurückzugeben, wenn der Rückgabewert nicht vorhanden ist oder nicht bestimmt werden kann.

Nehmen Sie die folgenden zwei Methoden als Beispiele:

string ReverseString(string stringToReverse) // takes a string and reverses it.
Person FindPerson(int personID)    // finds a Person with a matching personID.

In ReverseString() würde ich sagen, dass eine leere Zeichenfolge zurückgegeben wird, da der Rückgabetyp Zeichenfolge ist, sodass der Aufrufer dies erwartet. Auf diese Weise müsste der Anrufer auch nicht prüfen, ob ein NULL zurückgegeben wurde.

In FindPerson() scheint die Rückgabe von NULL besser zu passen. Unabhängig davon, ob NULL oder ein leeres Personenobjekt (new Person()) zurückgegeben wird, muss der Aufrufer überprüfen, ob das Personenobjekt NULL oder leer ist, bevor er etwas dagegen unternimmt (wie das Aufrufen von UpdateName()). Warum also nicht einfach NULL hier zurückgeben und dann muss der Anrufer nur noch nach NULL suchen.

Hat sonst noch jemand damit zu kämpfen? Jede Hilfe oder Einsicht wird geschätzt.

145
P B

StackOverflow hat eine gute Diskussion über genau dieses Thema in diesem Q & A . In der am besten bewerteten Frage stellt Kronoz fest:

Die Rückgabe von null ist normalerweise die beste Idee, wenn Sie angeben möchten, dass keine Daten verfügbar sind.

Ein leeres Objekt impliziert, dass Daten zurückgegeben wurden, während die Rückgabe von null eindeutig anzeigt, dass nichts zurückgegeben wurde.

Darüber hinaus führt die Rückgabe einer Null zu einer Null-Ausnahme, wenn Sie versuchen, auf Mitglieder im Objekt zuzugreifen. Dies kann hilfreich sein, um fehlerhaften Code hervorzuheben. Der Versuch, auf ein Mitglied von nichts zuzugreifen, macht keinen Sinn. Der Zugriff auf Mitglieder eines leeren Objekts schlägt nicht fehl, was bedeutet, dass Fehler unentdeckt bleiben können.

Persönlich möchte ich leere Zeichenfolgen für Funktionen zurückgeben, die Zeichenfolgen zurückgeben, um den Umfang der Fehlerbehandlung zu minimieren, die eingerichtet werden muss. Sie müssen jedoch sicherstellen, dass die Gruppe, mit der Sie arbeiten, der gleichen Konvention folgt. Andernfalls werden die Vorteile dieser Entscheidung nicht erreicht.

Wie im Poster in der Antwort SO vermerkt) angegeben, sollten Nullen wahrscheinlich zurückgegeben werden, wenn ein Objekt erwartet wird, damit kein Zweifel daran besteht, ob Daten zurückgegeben werden.

Am Ende gibt es keinen einzigen besten Weg, Dinge zu tun. Wenn Sie einen Teamkonsens aufbauen, werden letztendlich die Best Practices Ihres Teams verbessert.

81
JW8

In all dem Code, den ich schreibe, vermeide ich es, null von einer Funktion zurückzugeben. Ich habe das in Clean Code gelesen.

Das Problem bei der Verwendung von null ist, dass die Person, die die Schnittstelle verwendet, nicht weiß, ob null ein mögliches Ergebnis ist und ob sie danach suchen muss, da es keinen not null Referenztyp.

In F # können Sie einen option -Typ zurückgeben, der some(Person) oder none sein kann, sodass es für den Aufrufer offensichtlich ist, dass er prüfen muss.

Das analoge C # (Anti) Muster ist die Try... Methode:

public bool TryFindPerson(int personId, out Person result);

Jetzt weiß ich, dass die Leute gesagt haben, dass sie das Try... - Muster hassen , weil ein Ausgabeparameter die Ideen einer reinen Funktion bricht, aber es ist wirklich so nicht anders als:

class FindResult<T>
{
   public FindResult(bool found, T result)
   {
       this.Found = found;
       this.Result = result;
   }

   public bool Found { get; private set; }
   // Only valid if Found is true
   public T Result { get; private set;
}

public FindResult<Person> FindPerson(int personId);

... und um ehrlich zu sein, können Sie davon ausgehen, dass jeder .NET-Programmierer das Try... - Muster kennt, da es intern von der verwendet wird. NET-Framework. Das bedeutet, dass sie die Dokumentation nicht lesen müssen, um zu verstehen, was sie tut, was für mich wichtiger ist, als an der Sicht eines Puristen auf Funktionen festzuhalten ( Verständnis, dass result ein out Parameter ist, kein ref Parameter).

Also würde ich mit TryFindPerson gehen, weil Sie anscheinend angeben, dass es völlig normal ist, es nicht finden zu können.

Wenn es andererseits keinen logischen Grund gibt, warum der Aufrufer jemals ein personId angeben würde, das nicht existiert, würde ich wahrscheinlich Folgendes tun:

public Person GetPerson(int personId);

... und dann würde ich eine Ausnahme auslösen, wenn sie ungültig wäre. Das Präfix Get... Bedeutet, dass der Anrufer weiß, dass es erfolgreich sein sollte.

85
Scott Whitlock

Sie können Martin Fowlers Sonderfallmuster aus Paterns of Enterprise Application Architecture ausprobieren:

Nullen sind in objektorientierten Programmen umständlich, weil sie den Polymorphismus besiegen. Normalerweise können Sie foo frei für eine Variablenreferenz eines bestimmten Typs aufrufen, ohne sich Gedanken darüber machen zu müssen, ob es sich bei dem Element um den genauen Typ oder um eine Unterklasse handelt. Mit einer stark typisierten Sprache können Sie sogar den Compiler überprüfen lassen, ob der Aufruf korrekt ist. Da eine Variable jedoch null enthalten kann, kann es zu einem Laufzeitfehler kommen, indem Sie eine Nachricht auf null aufrufen, wodurch Sie eine nette, benutzerfreundliche Stapelverfolgung erhalten.

Wenn eine Variable null sein kann, müssen Sie daran denken, sie mit Null-Testcode zu umgeben, damit Sie das Richtige tun, wenn eine Null vorhanden ist. Oft ist das Richtige in vielen Kontexten dasselbe, so dass Sie an vielen Stellen ähnlichen Code schreiben - die Sünde der Codeduplizierung begehen.

Nullen sind ein häufiges Beispiel für solche Probleme, und andere treten regelmäßig auf. In Zahlensystemen muss man sich mit Unendlichkeit auseinandersetzen, die spezielle Regeln für Dinge wie Addition hat, die die üblichen Invarianten reeller Zahlen brechen. Eine meiner frühesten Erfahrungen mit Unternehmenssoftware war mit einem nicht vollständig bekannten Versorgungskunden, der als "Insasse" bezeichnet wurde. All dies impliziert eine Änderung des üblichen Verhaltens des Typs.

Anstatt null oder einen ungeraden Wert zurückzugeben, geben Sie einen Sonderfall zurück, der dieselbe Schnittstelle hat wie vom Aufrufer erwartet.

31
Thomas Owens

Ich würde denken, dass ReverseString() den umgekehrten String zurückgeben würde und ein IllegalArgumentException auslösen würde, wenn es in einem Null übergeben würde.

Ich denke, FindPerson() sollte dem NullObject Pattern folgen oder eine ungeprüfte Ausnahme auslösen, wenn etwas nicht gefunden wird, wenn Sie immer in der Lage sein sollten, etwas zu finden.

Mit Null umgehen zu müssen, sollte vermieden werden. Null in Sprachen zu haben, wurde von seinem Erfinder als Milliarden-Dollar-Fehler bezeichnet!

Ich nenne es meinen Milliardenfehler. Es war die Erfindung der Nullreferenz im Jahr 1965. Zu dieser Zeit entwarf ich das erste umfassende Typsystem für Referenzen in einer objektorientierten Sprache (ALGOL W).

Mein Ziel war es sicherzustellen, dass jede Verwendung von Referenzen absolut sicher ist, wobei die Überprüfung automatisch vom Compiler durchgeführt wird. Aber ich konnte der Versuchung nicht widerstehen, eine Nullreferenz einzufügen, einfach weil es so einfach zu implementieren war.

Dies hat zu unzähligen Fehlern, Schwachstellen und Systemabstürzen geführt, die in den letzten vierzig Jahren wahrscheinlich eine Milliarde Dollar an Schmerzen und Schäden verursacht haben.

In den letzten Jahren wurde eine Reihe von Programmanalysatoren wie PREfix und PREfast in Microsoft verwendet, um Referenzen zu überprüfen und Warnungen zu geben, wenn das Risiko besteht, dass sie nicht null sind. Neuere Programmiersprachen wie Spec # haben Deklarationen für Nicht-Null-Referenzen eingeführt. Dies ist die Lösung, die ich 1965 abgelehnt habe.

Tony Hoare

15
user7519

Geben Sie ein Option zurück. Alle Vorteile der Rückgabe eines anderen ungültigen Werts (z. B. leere Werte in Ihren Sammlungen) ohne das Risiko einer NullPointerException.

13
hugomg

Ich sehe beide Seiten dieses Arguments und stelle fest, dass einige ziemlich einflussreiche Stimmen (z. B. Fowler) dafür eintreten, keine Nullen zurückzugeben, um den Code sauber zu halten, zusätzliche Fehlerbehandlungsblöcke zu vermeiden usw.

Ich neige jedoch dazu, mich auf die Seite der Befürworter der Rückgabe von Null zu stellen. Ich finde, es gibt einen wichtigen Unterschied beim Aufrufen einer Methode und sie antwortet mit ich habe keine Daten und sie antwortet mit ich habe diese leere Zeichenfolge.

Stellen Sie sich das Szenario vor, in dem Sie versuchen, eine Instanz der Klasse nachzuschlagen, da einige der Diskussionen auf eine Personenklasse verweisen. Wenn Sie ein Finder-Attribut (z. B. eine ID) übergeben, kann ein Client sofort nach null suchen, um festzustellen, ob kein Wert gefunden wurde. Dies ist nicht unbedingt außergewöhnlich (daher sind keine Ausnahmen erforderlich), sollte aber auch klar dokumentiert werden. Ja, dies erfordert einige Sorgfalt seitens des Kunden, und nein, ich denke nicht, dass das überhaupt eine schlechte Sache ist.

Betrachten Sie nun die Alternative, bei der Sie ein gültiges Personenobjekt zurückgeben ... das nichts enthält. Fügen Sie in alle Werte (Name, Adresse, Favoritendrink) Nullen ein oder füllen Sie diese jetzt mit gültigen, aber leeren Objekten? Wie kann Ihr Kunde jetzt feststellen, dass keine tatsächliche Person gefunden wurde? Müssen sie überprüfen, ob der Name eine leere Zeichenfolge anstelle von null ist? Wird so etwas nicht tatsächlich zu so viel oder mehr Code-Unordnung und bedingten Anweisungen führen, als wenn wir nur nach Null gesucht und weitergemacht hätten?

Auch hier gibt es Punkte auf beiden Seiten dieses Arguments, denen ich zustimmen könnte, aber ich finde, dass dies für die meisten Menschen am sinnvollsten ist (wodurch der Code wartbarer wird).

8
RonU

Geben Sie null zurück, wenn Sie wissen müssen, ob das Element vorhanden ist oder nicht. Andernfalls geben Sie den erwarteten Datentyp zurück. Dies gilt insbesondere dann, wenn Sie eine Liste mit Elementen zurückgeben. Es ist normalerweise sicher anzunehmen, dass der Anrufer, wenn er eine Liste möchte, die Liste durchlaufen möchte. Viele (die meisten? Alle?) Sprachen schlagen fehl, wenn Sie versuchen, über Null zu iterieren, aber nicht, wenn Sie über eine leere Liste iterieren.

Ich finde es frustrierend, Code wie diesen zu verwenden, nur damit er fehlschlägt:

for thing in get_list_of_things() {
    do_something_clever(thing)
}

Ich sollte keinen Sonderfall für den Fall hinzufügen müssen, wenn es keine Dinge gibt.

6
Bryan Oakley

Dies hängt von der Semantik der Methode ab. Sie können möglicherweise angeben, dass Ihre Methode nur "Nicht null" akzeptiert. In Java können Sie dies mithilfe einiger Metadatenanmerkungen deklarieren:

string ReverseString(@NotNull String stringToReverse)

Sie sollten den Rückgabewert irgendwie angeben. Wenn Sie deklarieren, dass Sie nur NotNull-Werte akzeptieren, müssen Sie eine leere Zeichenfolge zurückgeben (wenn die Eingabe auch eine leere Zeichenfolge war).

Der zweite Fall ist in seiner Semantik etwas kompliziert. Wenn diese Methode darin besteht, eine Person anhand ihres Primärschlüssels zurückzugeben (und die Person voraussichtlich existiert), ist es besser, eine Ausnahme auszulösen.

Person FindPerson(int personID)

Wenn Sie eine Person anhand einer erratenen ID suchen (was mir seltsam erscheint), sollten Sie diese Methode besser als @Nullable deklarieren.

5
Martin Vejmelka

Ich würde empfehlen, wann immer möglich das Null-Objekt-Muster zu verwenden. Es vereinfacht den Code beim Aufrufen Ihrer Methoden und Sie können hässlichen Code nicht wie lesen

if (someObject != null && someObject.someMethod () != whateverValue)

Wenn eine Methode beispielsweise eine Sammlung von Objekten zurückgibt, die zu einem Muster passen, ist die Rückgabe einer leeren Sammlung sinnvoller als die Rückgabe von null, und das Durchlaufen dieser leeren Sammlung führt praktisch zu keinen Leistungseinbußen. Ein anderer Fall wäre eine Methode, die die zum Protokollieren von Daten verwendete Klasseninstanz zurückgibt. Meiner Meinung nach ist die Rückgabe eines Null-Objekts anstelle von null vorzuziehen, da Benutzer nicht gezwungen werden, immer zu überprüfen, ob die zurückgegebene Referenz null ist.

In Fällen, in denen die Rückgabe von null sinnvoll ist (z. B. Aufruf der Methode findPerson ()), würde ich versuchen, zumindest eine Methode bereitzustellen, die zurückgibt, wenn das Objekt vorhanden ist (z. B. personExists (int personId)). Ein weiteres Beispiel wäre die Methode containsKey () auf einer Map in Java. Dadurch wird der Code des Anrufers sauberer, da Sie leicht erkennen können, dass das gewünschte Objekt möglicherweise nicht verfügbar ist (Person existiert nicht, Schlüssel ist in der Karte nicht vorhanden). Die ständige Überprüfung, ob eine Referenz null ist, verschleiert meiner Meinung nach den Code.

3
Laf

null ist genau dann die beste Rückgabe, wenn die folgenden Bedingungen erfüllt sind:

  • das Nullergebnis ist im normalen Betrieb erwartet. Es ist zu erwarten, dass Sie unter bestimmten Umständen möglicherweise keine Person finden können. Daher ist findPerson (), das null zurückgibt, in Ordnung. Wenn es sich jedoch um einen wirklich unerwarteten Fehler handelt (z. B. in einer Funktion namens saveMyImportantData ()), sollten Sie eine Ausnahme auslösen. Der Name enthält einen Hinweis - Ausnahmen gelten für außergewöhnliche Umstände!
  • null bedeutet "nicht gefunden/kein Wert". Wenn Sie etwas anderes meinen, dann geben Sie etwas anderes zurück! Gute Beispiele wären Gleitkommaoperationen, die Infinity oder NaN zurückgeben. Dies sind Werte mit bestimmten Bedeutungen. Es wäre also sehr verwirrend, wenn Sie hier null zurückgeben würden.
  • Die Funktion ist soll einen einzelnen Wert zurückgeben, z. B. findPerson (). Wenn es entworfen wurde, um eine Sammlung zurückzugeben, z. findAllOldPeople () dann ist eine leere Sammlung am besten. Eine Folge davon ist, dass eine Funktion, die eine Sammlung zurückgibt , niemals null zurückgeben sollte.

Stellen Sie außerdem sicher, dass Sie dokumentieren Sie die Tatsache, dass die Funktion null zurückgeben kann.

Wenn Sie diese Regeln befolgen, sind Nullen meist harmlos. Beachten Sie, dass Sie normalerweise unmittelbar danach eine NullPointerException erhalten, wenn Sie vergessen, nach null zu suchen. Dies ist normalerweise ein ziemlich einfach zu behebender Fehler. Dieser Fail-Fast-Ansatz ist viel besser als ein gefälschter Rückgabewert (z. B. eine leere Zeichenfolge), der sich leise auf Ihrem System verbreitet und möglicherweise Daten beschädigt, ohne eine Ausnahme auslösen.

Wenn Sie diese Regeln schließlich auf die beiden in der Frage aufgeführten Funktionen anwenden:

  • FindPerson - Es wäre angemessen, wenn diese Funktion null zurückgibt, wenn die Person nicht gefunden wurde
  • ReverseString - scheint niemals ein Ergebnis zu finden, wenn eine Zeichenfolge übergeben wird (da alle Zeichenfolgen einschließlich der leeren Zeichenfolge umgekehrt werden können). Es sollte also niemals null zurückgeben. Wenn etwas schief geht (nicht genügend Speicher?), Sollte es eine Ausnahme auslösen.
3
mikera

Meiner Meinung nach gibt es einen Unterschied zwischen der Rückgabe von NULL, der Rückgabe eines leeren Ergebnisses (z. B. der leeren Zeichenfolge oder einer leeren Liste) und dem Auslösen einer Ausnahme.

Normalerweise gehe ich folgendermaßen vor. Ich betrachte einen Funktions- oder Methodenaufruf f (v1, ..., vn) als Anwendung einer Funktion

f : S x T1 x ... x Tn -> T

dabei ist S it der "Zustand der Welt" T1, ..., Tn die Art der Eingabeparameter und T der Rückgabetyp.

Ich versuche zuerst, diese Funktion zu definieren. Wenn die Funktion teilweise ist (d. H. Es gibt einige Eingabewerte, für die sie nicht definiert ist), gebe ich NULL zurück, um dies zu signalisieren. Dies liegt daran, dass die Berechnung normal beendet werden soll und mir mitgeteilt wird, dass die von mir angeforderte Funktion für die angegebenen Eingaben nicht definiert ist. Die Verwendung von beispielsweise einer leeren Zeichenfolge als Rückgabewert ist nicht eindeutig, da die Funktion möglicherweise in den Eingaben definiert ist und die leere Zeichenfolge das richtige Ergebnis ist.

Ich denke, die zusätzliche Prüfung für einen NULL-Zeiger im aufrufenden Code ist notwendig, weil Sie eine Teilfunktion anwenden und es die Aufgabe der aufgerufenen Methode ist, Ihnen zu sagen, ob die Funktion für die gegebene nicht definiert ist Eingang.

Ich bevorzuge es, Ausnahmen für Fehler zu verwenden, die es nicht erlauben, die Berechnung durchzuführen (d. H. Es war nicht möglich, eine Antwort zu finden).

Angenommen, ich habe eine Klasse Customer und möchte eine Methode implementieren

Customer findCustomer(String customerCode)

nach einem Kunden in der Anwendungsdatenbank anhand seines Codes zu suchen. Bei dieser Methode würde ich

  • Gibt ein Objekt der Klasse Customer zurück, wenn die Abfrage erfolgreich ist.
  • Geben Sie null zurück, wenn die Abfrage keinen Kunden findet.
  • Lösen Sie eine Ausnahme aus, wenn keine Verbindung zur Datenbank hergestellt werden kann.

Die zusätzlichen Überprüfungen auf Null, z.

Customer customer = findCustomer("...");
if (customer != null && customer.getOrders() > 0)
{
    ...
}

sind Teil der Semantik meiner Arbeit und ich würde sie nicht einfach "überspringen", um den Code besser lesen zu können. Ich halte es nicht für eine gute Praxis, die Semantik des vorliegenden Problems zu vereinfachen, nur um den Code zu vereinfachen.

Da die Prüfung auf Null sehr häufig erfolgt, ist es natürlich gut, wenn die Sprache eine spezielle Syntax dafür unterstützt.

Ich würde auch in Betracht ziehen, das Null-Objekt-Muster (wie von Laf vorgeschlagen) zu verwenden, solange ich das Null-Objekt einer Klasse von allen anderen Objekten unterscheiden kann.

1
Giorgio

Hinzufügen zu dem, was die Leute bereits über den Konstruktor vom Typ Maybe gesagt haben:

Ein weiterer großer Gewinn, abgesehen davon, dass NPEs nicht riskiert werden, ist der semantische. In der funktionalen Welt, in der wir uns mit reinen Funktionen befassen, versuchen wir gerne, Funktionen zu erstellen, die bei Anwendung genau ihrem Rückgabewert entsprechen. Betrachten Sie den Fall von String.reverse(): Dies ist eine Funktion, bei der eine bestimmte Zeichenfolge die umgekehrte Version dieser Zeichenfolge darstellt. Wir wissen, dass diese Zeichenfolge existiert, da jede Zeichenfolge umgekehrt werden kann (Zeichenfolgen sind grundsätzlich geordnete Zeichensätze).

Was ist nun mit findCustomer(int id)? Diese Funktion repräsentiert den Kunden mit der angegebenen ID. Dies ist etwas, das existieren kann oder nicht. Denken Sie jedoch daran, dass Funktionen einen einzelnen Rückgabewert haben. Sie können also nicht wirklich sagen, dass diese Funktion einen Kunden mit der angegebenen ID zurückgibt. [~ # ~] oder [~ # ~] Sie gibt null zurück .

Dies ist mein Hauptproblem sowohl bei der Rückgabe von null als auch bei der Rückgabe eines Nullobjekts. Sie sind irreführend. null ist kein Kunde und es ist auch nicht wirklich "die Abwesenheit eines Kunden". Es ist das Fehlen von ALLES. Es ist nur ein typloser Hinweis auf NICHTS. Sehr niedrig und sehr hässlich und sehr fehleranfällig. Ein Null-Objekt ist auch hier ziemlich irreführend, denke ich. Ein Null-Kunde IS ein Kunde. Es ist nicht das Fehlen eines Kunden, es ist nicht der Kunde mit der angeforderten ID, daher ist die Rücksendung einfach FALSCH. Dies ist NICHT der Kunde, nach dem ich gefragt habe, aber Trotzdem behaupten Sie, Sie hätten einen Kunden zurückgegeben. Er hat die falsche ID. Dies ist eindeutig ein Fehler. Er bricht den Vertrag, der durch den Methodennamen und die Signatur vorgeschlagen wird. Der Kundencode muss Dinge über Ihr Design annehmen oder die Dokumentation lesen.

Beide Probleme werden durch einen Maybe Customer Gelöst. Plötzlich sagen wir nicht mehr "diese Funktion repräsentiert den Kunden mit der angegebenen ID". Wir sagen "diese Funktion repräsentiert den Kunden mit der angegebenen ID falls vorhanden. Es ist jetzt sehr klar und explizit, was es tut. Wenn Sie nach dem Kunden mit einer nicht vorhandenen ID fragen Sie erhalten Nothing. Wie ist das besser als null? Nicht nur für das NPE-Risiko. Aber auch, weil der Typ von Nothing nicht nur Maybe ist. Es ist Maybe Customer. Es hat semantische Bedeutung. Es bedeutet speziell " die Abwesenheit eines Kunden ", was darauf hinweist, dass ein solcher Kunde nicht existiert.

Ein weiteres Problem mit null ist natürlich, dass es nicht eindeutig ist. Haben Sie den Kunden nicht gefunden oder gab es einen Datenbankverbindungsfehler oder darf ich diesen Kunden einfach nicht sehen?

Wenn Sie mehrere Fehlerfälle wie diesen behandeln müssen, können Sie entweder Ausnahmen für diese Versionen auslösen oder (und ich bevorzuge dies) einen Either CustomerLoadError Customer Zurückgeben, der entweder einen Fehler darstellt oder den zurückgegebenen Kunden. Es bietet alle Vorteile von Maybe Customer Und ermöglicht Ihnen gleichzeitig anzugeben, was schief gehen kann.

Die Hauptsache, nach der ich suche, ist, den Vertrag der Funktion in seiner Signatur zu erfassen. Nehmen Sie keine Dinge an, verlassen Sie sich nicht auf flüchtige Konventionen, seien Sie explizit.

1
sara

1) Wenn die Semantik der Funktion darin besteht, dass sie nichts zurückgeben kann, MUSS der Anrufer darauf testen, sonst wird er z. Nimm dein Geld und gib es niemandem.

2) Es ist gut, Funktionen zu erstellen, die semantisch immer etwas zurückgeben (oder werfen).

Mit einem Logger ist es sinnvoll, einen Logger zurückzugeben, der nicht protokolliert, wenn kein Logger definiert wurde. Bei der Rückgabe einer Sammlung ist es fast nie sinnvoll (außer auf "niedrig genug" Ebene, wo die Sammlung selbst DIE Daten sind, nicht das, was sie enthält), nichts zurückzugeben, da eine leere Menge eine Menge ist, nicht nichts.

Mit einem person Beispiel würde ich den "Ruhezustand" gehen (get vs load, IIRC, aber dort wird es durch Proxy-Objekte für das verzögerte Laden kompliziert), zwei Funktionen zu haben, eine, die null und eine zweite zurückgibt wirft.

0
user470365

Methoden, die Sammlungen zurückgeben, sollten leer zurückgeben, andere können jedoch null zurückgeben, da bei den Sammlungen möglicherweise Objekte vorhanden sind, die jedoch keine Elemente enthalten, sodass der Aufrufer nur die Größe und nicht beide überprüft.

0
Phani

Für mich gibt es hier zwei Fälle. Wenn Sie eine Liste zurückgeben, sollten Sie die Liste immer zurückgeben, egal was passiert, leer, wenn Sie nichts zum Einfügen haben.

Der einzige Fall, in dem ich eine Debatte sehe, ist, wenn Sie einen einzelnen Artikel zurücksenden. Ich ziehe es vor, im Falle eines Fehlers in einer solchen Situation null zurückzugeben, weil die Dinge schnell scheitern.

Wenn Sie ein Nullobjekt zurückgeben und der Aufrufer ein reales Objekt benötigt, versucht er möglicherweise, das Nullobjekt zu verwenden, was zu unerwartetem Verhalten führt. Ich denke, es ist besser für die Routine, einen Boom zu erleben, wenn sie vergessen, sich mit der Situation auseinanderzusetzen. Wenn etwas nicht stimmt, möchte ich so schnell wie möglich eine Ausnahme. Es ist weniger wahrscheinlich, dass Sie einen Fehler auf diese Weise versenden.

0
Loren Pechtel