Wenn null schlecht ist, warum implementieren moderne Sprachen es? [geschlossen]

Ich bin sicher, dass Designer von Sprachen wie Java oder C # Probleme mit der Existenz von Nullreferenzen kannten (siehe Sind Nullreferenzen wirklich eine schlechte Sache? ). Auch das Implementieren eines Optionstyps ist nicht viel komplexer als Nullreferenzen.

Warum haben sie sich überhaupt dafür entschieden? Ich bin sicher, dass das Fehlen von Nullreferenzen sowohl von Sprachentwicklern als auch von Benutzern zu einer besseren Codequalität (insbesondere zu einem besseren Bibliotheksdesign) führen (oder diese sogar erzwingen) würde.

Ist es einfach wegen des Konservativismus - "andere Sprachen haben es, wir müssen es auch haben ..."?

Haftungsausschluss: Da ich keinen Sprachdesigner persönlich kenne, ist jede Antwort, die ich Ihnen gebe, spekulativ.

Von Tony Hoare selbst:

Ich nenne es meinen Milliarden-Dollar-Fehler. Es war die Erfindung der Nullreferenz im Jahr 1965. Damals entwarf ich das erste umfassende Typensystem 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, Sicherheitslücken und Systemabstürzen geführt, die in den letzten vierzig Jahren wahrscheinlich eine Milliarde Dollar an Schmerzen und Schäden verursacht haben.

Betonung meiner.

Natürlich schien es ihm damals keine schlechte Idee zu sein. Es ist wahrscheinlich, dass es zum Teil aus dem gleichen Grund verewigt wurde - wenn es für den mit dem Turing Award ausgezeichneten Erfinder von Quicksort eine gute Idee war, ist es nicht verwunderlich, dass viele Menschen immer noch nicht verstehen, warum es böse ist. Zum Teil ist dies auch deshalb wahrscheinlich, weil es praktisch ist, wenn neue Sprachen älteren Sprachen ähnlich sind, sowohl aus Marketing- als auch aus Lernkurvengründen. Ein typisches Beispiel:

"Wir waren hinter den C ++ - Programmierern her. Wir haben es geschafft, viele von ihnen auf halbem Weg nach Lisp zu ziehen." -Guy Steele, Co-Autor der Java-Spezifikation

(Quelle: http://www.paulgraham.com/icad.html )

Und natürlich hat C ++ null, weil C null hat, und es besteht keine Notwendigkeit, auf die historischen Auswirkungen von C einzugehen. C # löste J ++ ab, das die Java-Implementierung von Microsoft war, und C ++ wurde als bevorzugte Sprache für die Windows-Entwicklung abgelöst.

BEARBEITEN Hier ist ein weiteres Zitat von Hoare, das es wert ist, in Betracht gezogen zu werden:

Programmiersprachen sind insgesamt sehr viel komplizierter als früher: Objektorientierung, Vererbung und andere Merkmale werden vom Standpunkt einer kohärenten und wissenschaftlich fundierten Disziplin oder einer Korrektheitstheorie noch nicht wirklich durchdacht . Mein ursprüngliches Postulat, das ich mein ganzes Leben lang als Wissenschaftler verfolgt habe, ist, dass man die Kriterien der Korrektheit verwendet, um sich auf ein anständiges Programmiersprachendesign zu konzentrieren - eines, das seinen Benutzern keine Fallen stellt, und eines, in dem sie sich befinden Wobei die verschiedenen Komponenten des Programms eindeutig verschiedenen Komponenten seiner Spezifikation entsprechen, so dass Sie kompositorisch darüber nachdenken können. [...] Die Werkzeuge, einschließlich des Compilers, müssen auf einer Theorie basieren, was es bedeutet, ein korrektes Programm zu schreiben. -Oral History Interview von Philip L. Frana, 17. Juli 2002, Cambridge, England; Charles Babbage Institute, Universität von Minnesota. [ Http://www.cbi.umn.edu/oh/display.phtml?id=343]

Wieder meine Betonung. Sun / Oracle und Microsoft sind Unternehmen, und das Endergebnis eines Unternehmens ist Geld. Die Vorteile für sie nullkönnten die Nachteile überwiegen, oder sie hatten einfach eine zu enge Frist, um das Problem vollständig zu prüfen. Als Beispiel für einen anderen Sprachfehler, der wahrscheinlich aufgrund von Fristen aufgetreten ist:

Es ist eine Schande, dass Cloneable kaputt ist, aber es passiert. Die ursprünglichen Java-APIs wurden innerhalb kürzester Zeit erstellt, um ein schließendes Marktfenster zu erreichen. Das ursprüngliche Java-Team hat einen unglaublichen Job gemacht, aber nicht alle APIs sind perfekt. Klonbar ist eine Schwachstelle, und ich denke, die Leute sollten sich ihrer Grenzen bewusst sein. -Josh Bloch

(Quelle: http://www.artima.com/intv/bloch13.html )

Ich bin sicher, dass Designer von Sprachen wie Java oder C # Probleme im Zusammenhang mit der Existenz von Nullreferenzen kannten

Na sicher.

Auch das Implementieren eines Optionstyps ist nicht viel komplexer als Nullreferenzen.

Ich bin anderer Ansicht! Die Entwurfsüberlegungen, die in C # 2 zu nullwertfähigen Werttypen führten, waren komplex, kontrovers und schwierig. Sie nahmen den Designteams sowohl der Sprachen als auch der Laufzeit viele Monate Debatte, Implementierung von Prototypen usw. ab, und tatsächlich wurde die Semantik des nullbaren Boxens sehr nahe an Versand C # 2.0 geändert, was sehr umstritten war.

Warum haben sie sich überhaupt dafür entschieden?

Jedes Design ist ein Prozess der Auswahl unter vielen subtilen und grob inkompatiblen Zielen. Ich kann nur einen kurzen Überblick über einige der Faktoren geben, die berücksichtigt werden sollten:

• Die Orthogonalität von Sprachmerkmalen wird im Allgemeinen als eine gute Sache angesehen. C # verfügt über nullfähige Werttypen, nicht nullfähige Werttypen und nullfähige Referenztypen. Nicht nullbare Referenztypen existieren nicht, wodurch das Typensystem nicht orthogonal ist.

• Die Kenntnis der vorhandenen Benutzer von C, C ++ und Java ist wichtig.

• Einfache Interoperabilität mit COM ist wichtig.

• Eine einfache Interoperabilität mit allen anderen .NET-Sprachen ist wichtig.

• Eine einfache Interoperabilität mit Datenbanken ist wichtig.

• Die Konsistenz der Semantik ist wichtig; Wenn wir den Verweis TheKingOfFrance gleich null haben, heißt das dann immer "es gibt keinen König von Frankreich im Moment", oder heißt das auch "es gibt definitiv einen König von Frankreich; ich weiß nur nicht, wer es im Moment ist"? oder kann es bedeuten, dass "die Vorstellung, einen König in Frankreich zu haben, unsinnig ist, also stell nicht einmal die Frage!"? Null kann all diese Dinge und mehr in C # bedeuten, und all diese Konzepte sind nützlich.

• Leistungskosten sind wichtig.

• Es ist wichtig, für statische Analysen zugänglich zu sein.

• Die Konsistenz des Typsystems ist wichtig; können wir immer wissen , dass ein Nicht-Nullable - Referenz ist nie unter irgendwelchen Umständen beobachtet ungültig sein? Was ist mit dem Konstruktor eines Objekts mit einem nicht nullwertfähigen Referenzfeldtyp? Was ist mit dem Finalizer eines solchen Objekts, bei dem das Objekt finalisiert wird, weil der Code, der den Verweis ausfüllen sollte, eine Ausnahme ausgelöst hat ? Ein Typensystem, das Sie über seine Garantien belügt, ist gefährlich.

• Und was ist mit der Konsistenz der Semantik? NULL- Werte werden bei Verwendung weitergegeben, aber NULL- Referenzen lösen bei Verwendung Ausnahmen aus. Das ist inkonsistent; Ist diese Inkonsistenz durch irgendeinen Nutzen gerechtfertigt?

• Können wir die Funktion implementieren, ohne andere Funktionen zu beeinträchtigen? Welche anderen möglichen zukünftigen Funktionen schließt die Funktion aus?

• Sie ziehen mit der Armee in den Krieg, die Sie haben, nicht mit der, die Sie wollen. Denken Sie daran, dass in C # 1.0 keine Generika vorhanden waren. Daher ist das Sprechen Maybe<T>als Alternative ein absoluter Nichtstarter. Sollte .NET für zwei Jahre verrutschen, während das Runtime-Team Generika hinzufügte, nur um Nullreferenzen zu beseitigen?

• Was ist mit der Konsistenz des Typsystems? Sie können Nullable<T>für jeden Werttyp sagen - nein, warten Sie, das ist eine Lüge. Das kannst du nicht sagen Nullable<Nullable<T>>. Solltest du in der Lage sein? Wenn ja, wie lautet die gewünschte Semantik? Lohnt es sich, das gesamte Typensystem nur für diese Funktion mit einem Sonderfall auszustatten?

Und so weiter. Diese Entscheidungen sind komplex.

Null dient einem sehr gültigen Zweck, einen Mangel an Wert darzustellen.

Ich werde sagen, dass ich die lautstärkste Person bin, die ich über die Missbräuche von Null und all die Kopfschmerzen und Leiden, die sie verursachen können, weiß, besonders wenn sie großzügig eingesetzt werden.

Mein persönlicher Standpunkt ist, dass Menschen Nullen nur verwenden dürfen , wenn sie begründen können, dass dies notwendig und angemessen ist.

Beispiel zur Begründung von Nullen:

Das Sterbedatum ist in der Regel ein nullwertfähiges Feld. Es gibt drei mögliche Situationen mit Todesdatum. Entweder ist die Person gestorben und das Datum ist bekannt, die Person ist gestorben und das Datum ist unbekannt, oder die Person ist nicht tot und daher gibt es kein Todesdatum.

Das Todesdatum ist auch ein DateTime-Feld und hat keinen "unbekannten" oder "leeren" Wert. Es hat zwar das Standarddatum, das angezeigt wird, wenn Sie eine neue Datumszeit erstellen, die je nach verwendeter Sprache variiert. Technisch gesehen besteht jedoch die Möglichkeit, dass die Person zu diesem Zeitpunkt tatsächlich gestorben ist und als Ihr "leerer Wert" gekennzeichnet wird, wenn Sie dies tun würden Verwenden Sie das Standarddatum.

Die Daten müssten die Situation richtig darstellen.

Person ist verstorben Sterbedatum bekannt (09.03.1984)

Einfach, '3/9/1984'

Person ist Todestag ist unbekannt

Also, was ist am besten? Null , '0/0/0000' oder '01 / 01/1869 '(oder was auch immer Ihr Standardwert ist?)

Person ist nicht tot Sterbedatum ist nicht anwendbar

Also, was ist am besten? Null , '0/0/0000' oder '01 / 01/1869 '(oder was auch immer Ihr Standardwert ist?)

Denken wir also über jeden Wert nach ...

• Null , es hat Konsequenzen und Bedenken, vor denen Sie vorsichtig sein müssen, wenn Sie versehentlich versuchen, es zu manipulieren, ohne zu bestätigen, dass es nicht null ist. Dies würde zum Beispiel eine Ausnahme auslösen, aber es repräsentiert auch die tatsächliche Situation am besten ... Wenn die Person nicht tot ist das Todesdatum existiert nicht ... es ist nichts ... es ist null ...
• 0/0/0000 , Dies könnte in einigen Sprachen in Ordnung sein und sogar eine angemessene Darstellung ohne Datum sein. Leider wird dies in einigen Sprachen und bei der Validierung als ungültige Datums- und Uhrzeitangabe abgelehnt, was in vielen Fällen zu einem Fehlschlag führt.
• 01.01.1869 (oder was auch immer Ihr voreingestellter Datums- / Uhrzeitwert ist) , das Problem hier ist, dass es schwierig wird, damit umzugehen . Sie könnten das als Wertmangel verwenden, außer was passiert, wenn ich alle meine Aufzeichnungen herausfiltern möchte, für die ich kein Sterbedatum habe? Ich könnte leicht Leute herausfiltern, die an diesem Datum tatsächlich gestorben sind, was zu Problemen mit der Datenintegrität führen könnte.

Die Tatsache , manchmal Sie Sie brauchen nichts zu vertreten und sicher manchmal ein Variablentyp eignet sich gut für das, aber oft Variablentypen müssen in der Lage sein , nichts zu vertreten.

Wenn ich keine Äpfel habe, habe ich 0 Äpfel, aber was ist, wenn ich nicht weiß, wie viele Äpfel ich habe?

Auf jeden Fall ist null missbraucht und möglicherweise gefährlich, aber es ist manchmal notwendig. In vielen Fällen ist dies nur die Standardeinstellung, denn bis ich einen Wert gebe, fehlt ein Wert und etwas muss ihn darstellen. (Null)

Ich würde nicht so weit gehen, wie "andere Sprachen es haben, wir müssen es auch haben ...", als wäre es eine Art Schritt mit den Joneses. Ein wichtiges Merkmal jeder neuen Sprache ist die Fähigkeit, mit vorhandenen Bibliotheken in anderen Sprachen zusammenzuarbeiten (siehe: C). Da C Nullzeiger hat, muss für die Interoperabilitätsschicht unbedingt das Konzept von Null gelten (oder ein anderes "nicht vorhandenes" Äquivalent, das bei Verwendung explodiert).

Die Sprache Designer könnten haben gewählt verwenden Option - Typen und zwingen Sie den Null - Pfad zu behandeln überall , dass die Dinge null sein könnten. Und das würde mit ziemlicher Sicherheit zu weniger Fehlern führen.

Die Verwendung von Optionstypen für diese Interoperabilitätsschicht hätte jedoch (insbesondere für Java und C # aufgrund des Zeitpunkts ihrer Einführung und ihrer Zielgruppe) wahrscheinlich geschadet, wenn ihre Annahme nicht torpediert worden wäre. Entweder wird der Optionstyp komplett durchgereicht, was die C ++ - Programmierer der mittleren bis späten 90er-Jahre nervt - oder die Interoperabilitätsschicht wirft Ausnahmen, wenn sie auf Nullen stößt, was die C ++ - Programmierer der mittleren bis späten 90er-Jahre nervt. ..

Ich denke, wir sind uns alle einig, dass ein Konzept der Nichtigkeit notwendig ist. Es gibt Situationen, in denen wir das Fehlen von Informationen darstellen müssen.

Das Zulassen von nullReferenzen (und Zeigern) ist nur eine Implementierung dieses Konzepts und möglicherweise die beliebteste, obwohl Probleme bekannt sind: C, Java, Python, Ruby, PHP, JavaScript usw. verwenden alle ein ähnliches Konzept null.

Warum ? Nun, was ist die Alternative?

In funktionalen Sprachen wie Haskell haben Sie den Typ Optionoder Maybe; diese bauen jedoch auf:

• parametrische Typen
• algebraische Datentypen

Hat das ursprüngliche C, Java, Python, Ruby oder PHP eine dieser Funktionen unterstützt? Nein. Javas fehlerhafte Generika sind neu in der Geschichte der Sprache und ich bezweifle irgendwie, dass die anderen sie überhaupt implementieren.

Hier hast du es. nullist einfach, parametrische algebraische Datentypen sind schwieriger. Die Leute entschieden sich für die einfachste Alternative.

Null / nil / none selbst ist nicht böse.

Wenn Sie seine irreführenden Namen berühmte Rede Schau „Milliarden - Dollar - Fehler“, Tony Hoare spricht darüber , wie so dass jede Variable der Lage sein , null zu halten , war ein großer Fehler. Die Alternative - mit Optionen - nicht nicht in der Tat von null Referenzen loszuwerden. Stattdessen können Sie angeben, welche Variablen null enthalten dürfen und welche nicht.

Tatsächlich unterscheiden sich Null-Dereferenzierungsfehler bei modernen Sprachen, die eine ordnungsgemäße Ausnahmebehandlung implementieren, nicht von anderen Ausnahmen - Sie finden sie, Sie beheben sie. Einige Alternativen zu Null-Referenzen (zum Beispiel das Null-Objekt-Muster) verbergen Fehler und führen dazu, dass Dinge erst viel später stillschweigend fehlschlagen. Meiner Meinung nach ist es viel besser, schnell zu scheitern .

Die Frage ist also, warum Sprachen Optionen nicht implementieren können. Tatsächlich kann die wohl beliebteste Sprache aller Zeiten in C ++ Objektvariablen definieren, die nicht zugewiesen werden können NULL. Dies ist eine Lösung für das "Null-Problem", das Tony Hoare in seiner Rede erwähnte. Warum hat die am weitesten verbreitete Schriftsprache Java sie nicht? Man könnte fragen, warum es im Allgemeinen so viele Mängel hat , insbesondere in seinem Typensystem. Ich glaube nicht, dass man wirklich sagen kann, dass Sprachen diesen Fehler systematisch begehen. Manche tun es, manche nicht.

Denn Programmiersprachen sind in der Regel eher praktisch als technisch korrekt. Tatsache ist, dass nullZustände aufgrund von fehlerhaften oder fehlenden Daten oder aufgrund eines noch nicht festgelegten Zustands häufig vorkommen. Die technisch überlegenen Lösungen sind umso unhandlicher, als Nullzustände zuzulassen und die Tatsache, dass Programmierer Fehler machen, in den Hintergrund zu rücken.

Wenn ich zum Beispiel ein einfaches Skript schreiben möchte, das mit einer Datei funktioniert, kann ich Pseudocode wie folgt schreiben:

file = openfile("joebloggs.txt")

for line in file
{
  print(line)
}

und es wird einfach fehlschlagen, wenn joebloggs.txt nicht existiert. Die Sache ist, dass für einfache Skripte, die wahrscheinlich in Ordnung sind, und für viele Situationen in komplexerem Code ich weiß, dass sie existieren und der Fehler nicht auftreten wird, was mich dazu zwingt, meine Zeit zu verschwenden. Die sichereren Alternativen erreichen ihre Sicherheit, indem sie mich zwingen, richtig mit dem potenziellen Ausfallstatus umzugehen, aber oft möchte ich das nicht, ich möchte einfach weiter.

Der Zeiger NULL(oder niloder Niloder nulloder Nothingoder was auch immer in Ihrer bevorzugten Sprache genannt wird) kann eindeutig und praktisch verwendet werden .

Für Sprachen ohne Ausnahmesystem (z. B. C) kann ein Nullzeiger als Fehlermarke verwendet werden, wenn ein Zeiger zurückgegeben werden soll. Zum Beispiel:

char *buf = malloc(20);
if (!buf)
{
    perror("memory allocation failed");
    exit(1);
}

Hier wird ein NULLzurückgegebener von malloc(3)als ein Marker des Scheiterns verwendet.

Wenn es in Methoden- / Funktionsargumenten verwendet wird, kann es den Standardwert für das Argument angeben oder das Ausgabeargument ignorieren. Beispiel unten.

Selbst für Sprachen mit Ausnahmemechanismus kann ein Nullzeiger als Hinweis auf einen weichen Fehler verwendet werden (dh auf Fehler, die behoben werden können), insbesondere wenn die Ausnahmebehandlung teuer ist (z. B. Objective-C):

NSError *err = nil;
NSString *content = [NSString stringWithContentsOfURL:sourceFile
                                         usedEncoding:NULL // This output is ignored
                                                error:&err];
if (!content) // If the object is null, we have a soft error to recover from
{
    fprintf(stderr, "error: %s\n", [[err localizedDescription] UTF8String]);
    if (!error) // Check if the parent method ignored the error argument
        *error = err;
    return nil; // Go back to parent layer, with another soft error.
}

In diesem Fall führt der Soft-Fehler nicht zum Absturz des Programms, wenn er nicht abgefangen wird. Dies beseitigt den verrückten Try-Catch, den Java hat, und hat eine bessere Kontrolle über den Programmfluss, da weiche Fehler nicht unterbrochen werden (und die wenigen verbleibenden harten Ausnahmen sind normalerweise nicht behebbar und bleiben unberührt).

Es gibt zwei verwandte, aber leicht unterschiedliche Probleme:

1. Sollte nulles überhaupt geben? Oder solltest du immer verwenden, Maybe<T>wo null nützlich ist?

2. Sollten alle Referenzen nullbar sein? Wenn nicht, welche sollte die Standardeinstellung sein?

   Wenn nullbare Verweistypen explizit als string?oder ähnlich deklariert werden müssen, werden die meisten (aber nicht alle) Probleme nullvermieden, ohne sich zu stark von den Programmierern zu unterscheiden, an die sie gewöhnt sind.

Ich stimme Ihnen zumindest zu, dass nicht alle Verweise nullwertfähig sein sollten. Aber die Vermeidung von Null ist nicht ohne Komplexität:

.NET initialisiert alle Felder auf, default<T>bevor verwalteter Code zum ersten Mal auf sie zugreifen kann. Dies bedeutet, dass Sie für Referenztypen nulloder etwas Äquivalentes Werttypen auf eine Art von Null initialisieren können, ohne Code auszuführen. Während beide schwerwiegende Nachteile haben, hat die Einfachheit der defaultInitialisierung diese Nachteile möglicherweise überwogen.

• Zum Beispiel Feldern können Sie durch die Forderung der Initialisierung von Feldern dieses Problem umgehen , bevor der Belichtungs thisZeiger auf verwalteten Code. Spec # ist diesen Weg gegangen und hat im Vergleich zu C # eine andere Syntax als die Konstruktorkettung verwendet.

• Stellen Sie bei statischen Feldern sicher, dass dies schwieriger ist, es sei denn, Sie schränken die Ausführung von Code in einem Feldinitialisierer stark ein, da Sie den thisZeiger nicht einfach ausblenden können .

• Wie initialisiere ich Arrays von Referenztypen? Betrachten Sie ein, List<T>das durch ein Array mit einer Kapazität größer als die Länge gesichert ist. Die übrigen Elemente , müssen sie etwas Wert.

Ein weiteres Problem ist, dass Methoden wie " bool TryGetValue<T>(key, out T value)which return" nicht zugelassen werden, default(T)als valueob sie nichts finden würden. In diesem Fall ist es jedoch leicht zu argumentieren, dass der out-Parameter in erster Linie ein schlechtes Design ist und diese Methode eine diskriminierende Union oder ein Vielleicht zurückgeben sollte.

All diese Probleme können gelöst werden, aber es ist nicht so einfach wie "Null verbieten und alles ist in Ordnung".

Die meisten nützlichen Programmiersprachen ermöglichen das Schreiben und Lesen von Datenelementen in willkürlichen Sequenzen, so dass es häufig nicht möglich ist, die Reihenfolge der Lese- und Schreibvorgänge vor dem Ausführen eines Programms statisch zu bestimmen. Es gibt viele Fälle, in denen Code tatsächlich nützliche Daten in jedem Slot speichert, bevor er gelesen wird, aber es schwierig ist, dies zu beweisen. Daher ist es häufig erforderlich, Programme auszuführen, bei denen es zumindest theoretisch möglich ist, dass der Code versucht, etwas zu lesen, das noch nicht mit einem nützlichen Wert geschrieben wurde. Unabhängig davon, ob dies für Code zulässig ist oder nicht, gibt es keine allgemeine Möglichkeit, den Versuch von Code zu stoppen. Die Frage ist nur, was passieren soll, wenn das passiert.

Unterschiedliche Sprachen und Systeme verfolgen unterschiedliche Ansätze.

• Ein Ansatz wäre zu sagen, dass jeder Versuch, etwas zu lesen, das nicht geschrieben wurde, einen sofortigen Fehler auslöst.

• Ein zweiter Ansatz besteht darin, dass Code an jeder Stelle einen Wert bereitstellen muss, bevor er gelesen werden kann, auch wenn der gespeicherte Wert semantisch nicht sinnvoll wäre.

• Ein dritter Ansatz besteht darin, das Problem einfach zu ignorieren und alles "natürlich" geschehen zu lassen.

• Ein vierter Ansatz ist zu sagen, dass jeder Typ einen Standardwert haben muss, und jeder Slot, der nicht mit etwas anderem geschrieben wurde, wird standardmäßig auf diesen Wert gesetzt.

Ansatz 4 ist weitaus sicherer als Ansatz 3 und im Allgemeinen billiger als Ansatz 1 und 2. Dann bleibt die Frage, wie der Standardwert für einen Referenztyp lauten soll. Für unveränderliche Referenztypen ist es in vielen Fällen sinnvoll, eine Standardinstanz zu definieren und zu sagen, dass der Standard für jede Variable dieses Typs ein Verweis auf diese Instanz sein sollte. Für veränderbare Referenztypen wäre dies jedoch nicht sehr hilfreich. Wenn versucht wird, einen veränderlichen Referenztyp zu verwenden, bevor er geschrieben wurde, gibt es im Allgemeinen keine sichere Vorgehensweise, außer zum Zeitpunkt des Verwendungsversuchs zu fangen.

Semantisch gesehen, wenn man ein Array customersvom Typ Customer[20]hat und es versucht, Customer[4].GiveMoney(23)ohne etwas gespeichert zu haben Customer[4], muss die Ausführung abfangen. Man könnte argumentieren, dass ein Customer[4]Leseversuch sofort abfangen sollte, anstatt zu warten, bis der Code versucht GiveMoney, aber es gibt genügend Fälle, in denen es nützlich ist, einen Slot zu lesen, herauszufinden, dass er keinen Wert enthält, und diesen dann zu nutzen Informationen, die besagen, dass der Leseversuch selbst fehlschlägt, sind oft ein großes Ärgernis.

In einigen Sprachen kann angegeben werden, dass bestimmte Variablen niemals Null enthalten dürfen, und jeder Versuch, eine Null zu speichern, sollte einen sofortigen Trap auslösen. Das ist eine nützliche Funktion. Im Allgemeinen muss jedoch jede Sprache, die es Programmierern ermöglicht, Arrays von Referenzen zu erstellen, entweder die Möglichkeit von Null-Array-Elementen zulassen oder die Initialisierung von Array-Elementen auf Daten erzwingen, die möglicherweise nicht aussagekräftig sind.