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

[Der schöne Günther]

Zitat von Uwe Raabe:

Was willst du uns mit dem Code jetzt sagen?

Zitat von DeddyH:

Ich dachte schon, ich sei der Einzige, der sich das fragt

Das Erkennen wird für Euch erst beginnen, wenn Ihr als Erkennende vom zu Erkennenden Abstand nehmt.

Seid Ihr soweit? Gut. Ich denke es ging um meine erste (nebensächliche Frage), ob wirklich erst der Destruktor aufgerufen und dann die Exception nach oben gereicht wird. Das hier scheint zu bestätigen: Ja, das ist so.



Um die Wogen der Verwirrung, was ich eigentlich wollte, noch etwas zu glätten: Ich hatte irgendwo im Destruktor eines Objekts (das seinen Konstruktor nicht vernünftig auf die Reihe bekam) einen Thread terminiert (myThread.Terminate()) der allerdings bislang noch garnicht initialisiert werden konnte.
Anstatt nun das zu erkennen (ich hatte vom zu Erkennenden als Nicht-Erkennender wohl noch nicht genug Abstand genommen) habe ich erst mal ein wirres Thema hier im Forum erstellt. Vielleicht hilft etwas weniger Kaffee in Zukunft dagegen...

[Aphton]

Ich war mir nicht ganz sicher, ob der Destruktor überhaupt aufgerufen wird
(klar logisch ists, dass er aufgerufen wird - wenn man mal drüber nachdenkt xD)
Weiters zeigt der Code einfach nur, dass es eben zu keinen Problemen im Destruktor
kommt, weil free nachprüft. Im Grunde wollt ich damit indirekt zeigen, dass er seine
Frage selber auch beantworten hätte können.. Aber pschtt..

[DeddyH]

Das muss alten Leuten doch auch mal gesagt werden *mitdemKrückstockwink*

[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;

[ConnorMcLeod]

Daß der Destructor zur Gänze durchlaufen wird bevor die Exception an die Oberfläche kommt.

[Aphton]

Also ich finde, dass es eig. ok ist, im Konstruktor die Objekte zu erzeugen. Ein absolut wichtiger Punkt beim sauberen Design - neu aufgeschnapt übrigens xD - jedoch ist, dass man nichtsa außer Instanzierung im Konstruktor betreibt - also keine Initialisierung über Methoden oder dergleichen.

Das Problem ist nämlich, wenn man bsp. eine virtuelle Methode zum initialisieren verwendet, kann und wird die von erbenden Klassen überschrieben werden. Üblicherweise hat man aber keine Kontrolle über die Implementierung dieser - dh. die überschreibende (initialisier-) Methode kann fälschlicherweise auf Felder/Objekte der Klasse zugreifen, die jedoch noch nicht initialisiert worden sind, weil die Methode eben erst im Konstruktor aufgerufen wird.

[sahimba]

Zitat von sx2008:

Diesen Zustand kann man aber dadurch abhelfen, dass man eine Setup-Methode hat, die das Objekt vollständig initialisiert

Das würde ich (fast) als klassisches Anti-Pattern bezeichnen.

[Der schöne Günther]

Um ganz ehrlich zu sein: Mir ist so ein Pseudo-Konstruktor, dessen eigentliche Arbeit dann im Endeffekt wieder von einer ganz normalen Instanzmethode übernommen wird, auch nicht wirklich sympathisch. Bislang sehe ich nur, dass man es besser nicht tun sollte, aber einen wirklichen Grund habe ich nicht.

Noch vor der ersten Zeile im Konstruktor sind Instanzmember bereits mit einem Standardwert initialisiert. Zahlen sind Null, Objekte nil und Strings sind '' (richtig?). Meine Frage ganz am Anfang kam von Verwirrung und der falschen Annahme, das sei nicht der Fall.


In meinem ganz konkreten Fall hat der Konstruktor die Exception sogar absichtlich geworfen: Unter den gegebenen Umständen war eine Erstellung eines sinnvollen Objekts nicht möglich. Kurioserweise war die Erstellung dieses Objekts (auf Umwegen) wiederum Bestandteil des Konstruktor eines anderen Objekts.
Wo liegt nun der Unterschied, wäre der Konstruktor hier nicht mit einer Exception ausgestiegen sondern hätte ein quasi nutzloses Objekt mit einem Flag "ichBinNichtZuGebrauchen:Bool" ausgespuckt? Im Endeffekt ist das doch noch aufwändiger und unübersichtlicher (und wahrscheinlich sogar fehleranfälliger) zu handhaben als eine "stinknormale" Exception.