Zugriffsverletzung beim Zerstören der TIniFile-Instanz

[TheSledgeHammer]

Zitat von Blup:

Free prüft selbst ob die Variable bereits nil ist, dann passiert nichts.
TObject(nil).Free; // läuft problemlos

Dazu noch ein kleiner Einwurf: ja, für System-Komponenten mag das alles zutreffend sein. Ich vertrete allerdings die Meinung, dass man so viel Routine wie möglich, auf die einfachste Art und Weise wie möglich bekommen soll - keep the common case simple and fast.

Ihr glaubt gar nicht, wie häufig ich schon bei Konstruktor-Aufrufen Exceptions bekommen habe; daher stehen die immer innerhalb des Try-Blocks. Und ich unterscheide nicht zwischen System-Klassen und "eigenen", da wirst ja sonst kirre! Und v.a. bringst du so was keinem Azubi bei Und eine schlechte Idee ist es auch nicht, wenn man Konstruktoren "absichert"; da sind schon die dollsten Sachen bei passiert!

Vorm Destruktor auf NIL zu prüfen, i.O., das sehe ich ein, das mag bei Delphi durchaus so geregelt sein, aber wer aus der C++ Ecke kommt, gewöhnt sich ganz schnell an, Objekte vorm Zerstören auf Gültigkeit zu prüfen Und auch hier unterscheide ich nicht: das mach ich im besten Fall immer so, dann kann ich's im Zweifelsfall auch nicht vergessen. Routine, Routine, Routine...

[jaenicke]

Zitat von TheSledgeHammer:

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.

[TheSledgeHammer]

Zitat von jaenicke:

Zitat von TheSledgeHammer:

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.

[jaenicke]

Kannst du vielleicht ein Beispielprojekt erstellen, das nur die DLL-Funktion aufruft? Wenn dann der Fehler noch passiert, kannst du ja vielleicht alles aus der DLL herauswerfen, das du nicht posten möchtest, solange der Fehler noch auftritt.
Denn mit einem funktionierenden Beispiel ließe sich das Problem hier sicher ganz schnell lösen.

Zitat von TheSledgeHammer:

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.

Ja, das ist ein Memory Leak, aber dagegen kannst du nichts tun. Wie gesagt: Wenn eine Exception im Konstruktor auftritt, wird der Variable nichts zugewiesen und sie ist dann, wenn sie vorher wie du geschrieben hast initialisiert wurde, schlicht nil. Wenn du es aber vergisst, gibt es Probleme.

Der Vorteil, den du in diesem Konstrukt siehst, ist zwar nachvollziehbar, kann aber in der Realität nie (!) eintreten.

Deshalb sollte man sich besser an den Standard halten. Der hat schon seinen Sinn.