Ich betrachte einen Code (Delphi 7) mit der folgenden Überprüfung ist oben bei jedem Methodenaufruf für ein bestimmtes Objekt:
%Vor%Ich vermute, dass dies mich daran hindern würde, eine Methode für einen Null-Objekt-Zeiger aufzurufen. Aber ich würde eine Ausnahme bekommen, sobald ich in diesem Fall versucht habe, auf die Mitgliedsdaten zuzugreifen, oder?
Ist das eine Art von Standard, die ich noch nie zuvor gesehen habe? Das Objekt stammt von TPersistent.
Sie können eine Instanzmethode für einen Null-Zeiger aufrufen, obwohl dies nicht der Fall ist, den Sie absichtlich ausführen möchten. Wenn das passiert, wird die Ausführung ziemlich glücklich fortgesetzt, bis sie auf die Instanzdaten zugreifen muss und dann alles knallt.
In diesem Fall würde die Suche nach nil Sie am Anfang der Prozedur warnen, damit Sie etwas anderes tun könnten, wie zum Beispiel das Protokollieren eines Stack-Trace. Oder Sie könnten einen Breakpoint auf die Raise-Linie setzen, damit Sie hineintauchen und sehen können, was passiert.
Das ist etwas, was ich tun könnte, wenn ich einen spezifischen Fehler hätte, den ich herausfinden wollte, wo eine Null-Referenz verwendet wurde.
Es macht mich regelmäßig als Code-Geruch.
Ein klarer Fehler, der sich über einen Null-Zeiger beschweren kann, ist besser als eine Zugriffsverletzung, die nicht sagt, wie es passiert ist.
Es gibt Zugriffsverletzungsszenarien, die dazu führen können, dass Code im Speicher ausgeführt wird, in dem Self null ist. Einige Programmierer, anstatt das eigentliche Problem zu lösen, versuchen solche Behauptungen zu umgehen, um Korruption zu verhindern. Ich würde sehr gut prüfen, ob diese Ausnahme jemals in der Laufzeit erhöht, wenn ja - Sie haben einen fehlerhaften Code unter Ihren Händen.
Sie können den folgenden Artikel über das Thema lesen: Wenn Self in Nil ... Sie wissen, dass Sie in Schwierigkeiten sind .
Eine andere Möglichkeit bezieht sich auf Ereignisse, hier können Sie mehr lesen, mit vielen Beispielen für solche Tests und entsprechenden Erklärungen: Multicast-Ereignisse - Teil 2 .
Dies ist eine Gelegenheit, die definitiv zu einem Absturz führen sollte (d. h. eine OS-Ausnahme wie "Lesen von Adresse 0x00000000"). Eine Sprachausnahme zu werfen ist einfach überflüssig (und es ist nicht sinnvoll, EAbstractError hier zu missbrauchen).
Das Überprüfen auf gültige Eingabeparameter ist keine durchführbare Aufgabe in einer unsicheren Sprache, da Sie niemals Gewissheit erlangen werden und somit Ihre Handhabung von ungültigen Parametern niemals konsistent sein wird. (Warum werfen Sie eine Exception, wenn ein Null-Zeiger übergeben wird, aber nicht für 0x00000001, was genauso ungültig ist?). Für eine technische Diskussion dieser Frage lesen Sie den Blog von Larry Osterman über warum nicht nach einem gültigen Test suchen Zeiger .
Eine Ausnahme sollte beachtet werden: In Delphi kann die Methode Free für einen Null-Zeiger aufgerufen werden, was natürlich diese Art der Überprüfung erfordert.
Und dann gibt es immer die Möglichkeit, dass der Code nicht abstürzt, wenn er mit nil Self läuft. Beispiel - wenn es nicht auf Felder des Eigentümerobjekts zugreift. In diesem Fall würde dieser Test das Problem aufspüren, das andernfalls unentdeckt bleiben würde.
Trotzdem führt das defensive Programmierung auf die Spitze. Ich mache das nie (OK, fast nie - nur wenn ich Wabbits jage ... errr ... Bugs quetschen) mach das.
Es scheint die ursprüngliche Absicht dieser Methode zu sein, dass sie zu einer abstrakten Methode wird.