Create <-> Exception?

[laz847]

Hallo, kurze Frage,

Code: Alles auswählen

TCPx = class 
 
TCPxHnd := TCPx.Create; 

Erzeugt eine neue Instanz der Klasse, danach kommt dann try f/e und end.

Ist klar, aber kann es beim Create nicht auch schon zu Fehlern kommen?

Setzt man das dann in 2 Blöcke oder wie macht man das ?

[mse]

Konstruktoren werden innerhalb eines impliziten try except Blockes ausgeführt. Falls eine exception auftritt, wird destroy() aufgerufen. destroy() muss also auch mit nur teilweise initialisierten Instanzen klarkommen.

Code: Alles auswählen

 
 TCPxHnd := TCPx.Create;
 try
  ...
 finally
  TCPxHnd.free(); //oder destroy() weil TCPxHnd hier sicher nicht nil ist
 end;
 

sollte genügen um Speicherlecks zu verhindern.

[m.fuchs]

Pack das Create doch in den Try-Block:

Code: Alles auswählen

var
  MyObject: TObject = nil;
begin
  try
    MyObject := TObject.Create;
    [...]
  finally
    FreeAndNil(MyObject);
  end;
end;

[mse]

Pack das Create doch in den Try-Block:

Das wäre dann doppelt gemoppelt.

[m.fuchs]

Warum?

[mse]

Weil Konstruktoren innerhalb eines impliziten try except Blockes ausgeführt werden, siehe oben. Wenn du durch den code stepst siehst du es. Für Delphi ist es auch dokumentiert:
http://docwiki.embarcadero.com/RADStudio/XE5/en/Methods

If an exception is raised during the execution of a constructor that was invoked on a class reference, the Destroy destructor is automatically called to destroy the unfinished object.

[m.fuchs]

Ja, aufgeräumt wird die Instanz schon. Aber die Exception wird ja trotzdem weitergereicht. Und dann ist das Create innerhalb des try-Blocks schon sinnvoll. Das .Free einmal unnötig aufgerufen wird, kann man vernachlässigen. Schließlich sollen Exceptions nicht im Sekundentakt vorkommen.

[mse]

Das ergibt aber das Problem, dass destroy() zwei mal aufgerufen wird, einmal implizit bei create() und ein zweites mal explizit im finally Block. In der Regel gibt das ein unschönes SIGSEGV.
Edit: Durch nil Initialisierung und free() funktioniert es, da die Zuweisung zur Instanzvariable wegen der exception nicht mehr ausgeführt wird.

[m.fuchs]

Ja, deswegen immer Objektvariablen mit nil initialisieren und brav FreeAndNil nutzen!

[Philos]

Das Create in den try-Block zu packen geht aber auch nur mit FreeAndNil. Wenn man nur ein .Free benutzt, hat das Create im Try-Block nichts zu suchen.

[m.fuchs]

Und wieder frage ich: warum?

[Philos]

Mein Gedanke ist folgender: ( bitte um Berichtigung, falls ich mich da täuschen sollte )

Wenn beim Create schon etwas schiefgeht, dann habe ich kein wirkliches Objekt erhalten an der Stelle oder nur irgendwas Undefiniertes, auf das ich zugreifen kann. Wenn wir dann bei einem Error gleich ins
Except oder Finally springen, versucht Free ETWAS zu löschen an der angeblichen Adresse von unserer Instanz, die ja nun aber alles mögliche sein kann (da wir ja annahmen, dass Create nicht geklappt hat ). Ich könnte mir vorstellen, dass dies einige ungewünschte Effekte haben könnte.

[mse]

Die Instanz-Variable wird nur nach erfolgreichem create() gesetzt. Problematisch sind Fälle wo die Instanz-Variable im code gesetzt wird, z.B. durch Application.CreateForm().

[m.fuchs]

FreeAndNil ruft ja intern auch nur Free auf. Und das wiederum prüft vorher, ob Self auf nil zeigt (http://www.freepascal.org/docs-html/rtl ... .free.html). Von daher kein Problem.

FreeAndNil hat eben nur den Vorteil, dass es die übergebene Referenzvariable auf nil zeigen lässt.

[laz847]

Genau den Gedanke hatte ich als ich die Frage stellte .

Mein Gedanke ist folgender: ( bitte um Berichtigung, falls ich mich da täuschen sollte )

Wenn beim Create schon etwas schiefgeht, dann habe ich kein wirkliches Objekt erhalten an der Stelle oder nur irgendwas Undefiniertes, auf das ich zugreifen kann. Wenn wir dann bei einem Error gleich ins
Except oder Finally springen, versucht Free ETWAS zu löschen an der angeblichen Adresse von unserer Instanz, die ja nun aber alles mögliche sein kann (da wir ja annahmen, dass Create nicht geklappt hat ). Ich könnte mir vorstellen, dass dies einige ungewünschte Effekte haben könnte.

Was ist wenn der Create fehlschlägt, deswegen die Frage ob man das dann sinnvollerweise in 2 Blöcke verschachtelt?

Übrigens:

obj := TObj.Create;
try
obj.DoSomething;
finally
obj.Free;
end;

Zuerst wird das Objekt erstellt – aber Achtung: dies darf nicht im try-Block geschehen! Tritt nämlich beim Erstellen des Objekts ein Fehler auf, wird das Objekt nicht erstellt und darf somit auch nicht freigegeben werden, was ansonsten im finally-Block geschehen würde. Da sich dieser Befehl aber außerhalb des try-Blocks befindet, wird der finally-Block bei einem Laufzeitfehler im Konstruktor nie ausgeführt.Dann wird im try-Block eine Methode des Objekts aufgerufen und am Ende wird es wieder freigegeben. Auch wenn die aufgerufene Methode fehlschlägt, wird das Objekt freigegeben.Im Allgemeinen ist es guter Programmierstil, nach einer Instanzierung von einem Objekt immer ein try…finally…end Konstrukt einzusetzen – egal wie fehlersicher die nachfolgenden Aufrufe sind.

http://www.delphi-treff.de/tipps-tricks ... -abfangen/

Wie ist es denn nun richtig???

Code: Alles auswählen

 obj := TObj.Create;
try
  obj.DoSomething;
finally
  obj.Free;
end; 

Code: Alles auswählen

 obj := TObj.Create;
try
  obj.DoSomething;
finally
  obj.FreeAndNil;
end; 

Code: Alles auswählen

 try
 obj := TObj.Create;
 try
   obj.DoSomething;
 finally
   obj.Free;
 end;
except
 // error log
end; 

Code: Alles auswählen

 obj := TObj.Create;
try
 try
   obj.DoSomething;
 finally
   obj.Free;
 end;
except
 // error log
end;