Ihr glaubt gar nicht, wie häufig ich schon bei Konstruktor-Aufrufen Exceptions bekommen habe; daher stehen die immer innerhalb des Try-Blocks.
Dadurch zerschießt du dir den Speicher aber. Denn wenn dort eine
Exception auftritt, ist die Variable gar nicht initialisiert. Es wird also ein Free auf einer pseudo-zufälligen Speicherstelle aufgerufen...
Du kannst ja außen herum noch einmal ein try..except setzen oder ähnliches, wenn du die Fehlerursache im Konstruktor nicht abstellen kannst, aber beim try..finally darf die Erstellung des Objekts aus dem genannten Grund nicht im try-Block stehen.
Aus diesem Grund setze ich die Variable zuvor auf NIL, in der Annahme, dass die Zuweisung der Variable ebenfalls unterbrochen wird, wenn eine
Exception im Konstruktor-Prozess ausgelöst wird. In diesem Fall sollte aber sowieso der innere Check von "Free" einschreiten, das hatten wir ja zuvor schon
Ist halt doppelt abgesichert
Das was du jetzt erwähnst, würde ja bedeuten, dass der "eigene" Konstruktor zwar abgebrochen würde, der vom TObject aber nicht. Wie himitsu in einem vorherigen Post erläutert hat, beginnt die Erzeugung des TObjects tatsächlich ja schon vor dem "begin". D.h. "eigene" Klassen machen nach dem
inherited Create
noch eigenes Zeug, was dann u.U. eine
Exception auslöst. Wenn das passiert, wird doch dann ein Memory Leak existieren, oder? Ich muss also, um diesen Leak zu eliminieren, irgendwo ein Free aufrufen, damit zumindest das TObject (und je nach Vererbung auch alle höheren Instanzen) wieder sauber zerstört wird.