Der Konstruktor ist abgestürzt - Wie gehe ich im Destruktor am besten vor?

[DeddyH]

Davon ausgehend, dass es sich bei den angesprochenen Objekten um private Felder der eigenen Klasse handelt, musst Du nichts weiter beachten. Diese sind initial nil, wenn Du sie also im Destruktor mit Free freigibst, passiert nichts, da Free erst auf nil prüft und dann erst Destroy aufruft. Daraus folgt: was nicht da ist, wird auch nicht versucht freizugeben.

[Der schöne Günther]

Tatsächlich. Ich bin durcheinandergekommen da der Debugger bei einer Exception im Konstruktor einen mit F7 nicht mehr durch den Destruktor wandern lässt soweit man nicht explizit einen Haltepunkt dort hineinsetzt.

Ich rede wirres Zeug, belassen wir es damit

[ConnorMcLeod]

Vllt bin ich jetzt auf dem falschen Dampfer, aber was spricht gegen FreeAndNil ?

[DeddyH]

Im Prinzip nichts, aber Free genügt in diesem Falle auch.

[Klaus01]

.. freeAndNil erzeugt eine Exception wenn die freizugebene Instanz nicht mehr existiert.

Grüße
Klaus

[flipdascript]

Zitat von Klaus01:

.. freeAndNil erzeugt eine Exception wenn die freizugebene Instanz nicht mehr existiert.

Grüße
Klaus

Aber nur, wenn die Referenz <> nil ist. Das ist keine Einschränkung von FreeAndNil. In dem Fall würde es bei Referenz.Free genauso knallen.

[Aphton]

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

uses
  SysUtils;

type
  TMyBuggyObject = class
    PrivObject1: TObject;
    PrivObject2: TObject;
    constructor Create;
    destructor Destroy; override;
  end;

constructor TMyBuggyObject.Create;
begin
  Writeln('TMyBuggyObject.Create(): Allocating object1');
  PrivObject1 := TObject.Create;
  Writeln('TMyBuggyObject.Create(): Throwing exception');
  raise Exception.Create('TMyBuggyObject.Constructor - selfdestruct');
  Writeln('TMyBuggyObject.Create(): Allocating object2');
  PrivObject2 := TObject.Create;
end;

destructor TMyBuggyObject.Destroy;
begin
  Writeln('TMyBuggyObject.Destroy(): Im being called.');
  Writeln('TMyBuggyObject.Destroy(): PrivObj1=0x' + IntToHex(integer(PrivObject1), 8));
  Writeln('TMyBuggyObject.Destroy(): PrivObj2=0x' + IntToHex(integer(PrivObject2), 8));
  Writeln('TMyBuggyObject.Destroy(): Freeing both!');
  PrivObject2.Free;
  PrivObject1.Free;
  inherited;
end;

procedure main;
var
  Instance: TMyBuggyObject;
begin
  Instance := NIL;
  try
    Instance := TMyBuggyObject.Create;
    try
      Writeln('Maincode: No exception!');
    finally
      Instance.Free;
    end;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Writeln('Address of instance:'#9'0x', IntToHex(integer(Instance), 8));
  Readln;
end;

begin
  ReportMemoryLeaksOnShutdown := True;
  main;
end.

Code:

TMyBuggyObject.Create(): Allocating object1
TMyBuggyObject.Create(): Throwing exception
TMyBuggyObject.Destroy(): Im being called.
TMyBuggyObject.Destroy(): PrivObj1=0x00520D10
TMyBuggyObject.Destroy(): PrivObj2=0x00000000
TMyBuggyObject.Destroy(): Freeing both!
Exception: TMyBuggyObject.Constructor - selfdestruct
Address of instance:    0x00000000

[sx2008]

Also generell sollte man einen Konstruktor so schreiben das er keine Exception auslösen kann!!!
Das heisst also keine Resouren (mit Ausnahme von Speicher) belegen, keine Dateioperationen, keine problematischen Windows-API-Aufrufe, usw.

Die Folge ist aber, dass man dann evtl. ein unvollständig initialisiertes Objekt erhält.
Diesen Zustand kann man aber dadurch abhelfen, dass man eine Setup-Methode hat, die das Objekt vollständig initialisiert:

Delphi-Quellcode:

var
  meinobj : TMyClass;
begin
  meinobj := TMyClass.Create;
  try
    meinobj.Setup;
    mainobj.MachwasDamit;
  finally
    meinobj.Free;
  end;

Dies hat aber den unschönen Effekt, dass man mehr Schreibarbeit hat und dass man den Aufruf von Setup auch mal vergessen kann.
Dem kann aber abgeholfen werden, indem man die Setup-Methode so schreibt:

Delphi-Quellcode:

type
  TMyClass=class(TObject)
  private
    FSetupDone : Boolean;
  protected
    procedure Setup;virtual;
  public
    procedure MachWasDamit;
  end;

procedure TMyClass.Setup;
begin
  if not FSetupDone then
  begin
    // hier der Code der nicht in den Konstruktor soll, weil er potentiell eine Exception
    // auslösen kann
    ...
    FSetupDone := True;
  end;
end;

procedure TMyClass.MachWasDamit;
begin
  Setup; // wird jeder Methode von TMyClass aufgerufen, damit sichergestellt wird
  // dass das Objekt vollständig initialisert ist

  // hier der Code von MachWasDamit
  ..
end;

Ok, diese Methode bedeutet mehr Schreibarbeit und auch eine minimale Performanceverschlechterung aber man vermeidet so eine Exception im Konstruktor mit allen seinen hässlichen Konsequenzen.

Es gibt auch noch andere Möglichkeiten um Code im Konstruktor zu vermeiden, der potentiell eine Exception auslösen kann.
Stichwort: Dependeny Injection

Angenommen ein Thread soll in eine Datei loggen.
Im naiven Ansatz würde man das so machen:

Delphi-Quellcode:

constructor TMyThread.Create;
begin
  inherited Create;
  FLogger := TLogger.Create;
  // Gefahr!
  // hier kann eine Exception ausgelöst werden (z.B. keine Schreibrechte auf der Lodatei)
  FLogger.OpenLogfile('C:\log.txt');
end;

Bei der Dependency Injection würde die Threadklasse verlangen, dass ein geöffnetes (!) Logobjekt übergeben wird:

Delphi-Quellcode:

constructor TMyThread.Create(logger:TLogger);
begin
  inherited Create;
  FLogger := logger;  // das ist sicher; keine Exception möglich
end;