Exception im Konstruktor lösen Destructor aus auch bei Interfaces

[ColeZero]

Hallo!
Es war nicht so einfach ein Titel für mein Problem zu finden, ich hoffe er ist okay.
Ich habe folgendes Problem.

Ich habe eine Datenklasse TRepo, ein Repository welches Daten aus einer Datenbank hält und das Observer-Pattern implementiert hat. Wenn also eine Änderung an den Daten stattfindet z.b durch die Datenbank selbst, werden alle Observer benachrichtig z.b eine GUI. Die GUI füllt dann z.B. ein Grid neu.

Dann habe ich ein GUI-Fenster, welches ebenfalls eine Schnittstelle implementiert.

In Delphi sind ja die Schnittstellen in der Regel Referenzgezählt und sollte der Zähler auf Null fallen, wird das konkrete Objekt zerstört.

Jetzt passiert folgendes, ich hoffe ich kann es irgendwie erklären mittels Code.

Delphi-Quellcode:

unit Unit1;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs;

type

  { TGUIFenster }

  TGUIFenster = class(TGuiInterfaceBase, IDataObserver)
  private
    { private declarations }
    FRepo : TRepo;
    FMObject: TObject;
    procedure OnBeforeClose;
  public
    { public declarations }
    constructor Create(ASender : TObject;IDX : integer);overload;
    destructor Destroy;override;
  end;

implementation

{$R *.lfm}

{ TGUIFenster }

procedure TGUIFenster.OnBeforeClose;
begin
   {
    Prüfe auf Änderungen, die nicht gespeichert sind
    Trenne Verbindungen
    Schreibe Log
    etc..
    ...
   }
   FRepo.Detach(Self);
end;

constructor TGUIFenster.Create(ASender: TObject; IDX: integer);
var
  res : integer;
begin
  inherited Create(ASender, IDX);

  FMObject := TObject.Create;

  FRepo := NewDataRepository;
  FRepo.Attach(Self);
  FRepo.Open;
  res := 5 / 0;   //bewusste Exception löst direkt den Destructor Auf

end;

destructor TGUIFenster.Destroy;
begin
  FMObject.Free;
  {...
  ...}
  FRepo := nil;   //nimmt die einzige bisher existierende Referenz vom GUI-Fenster
                  //und zerstört dieses damit. Destructor wird 2x aufgerufen.
  inherited Destroy;
end;

end.

Ab Zeile " FRepo := NewDataRepository;" bis " FRepo.Open;" erstelle ein TRepo Objekt und füge die GUI selbst als Beobachter ein und öffne das Repository. Damit erhöht sich die Referenz vom GUI Element um 1.
Eine Zeile später verursache ich eine Exception, in dem Fall bewusst, dadurch wird unmittelbar der Destructor aufgerufen.
Der Destrutor setzt das TRepo auf nil, damit gibt es keine Referenz mehr auf das TRepo und es wird zerstört, alles soweit ok.
Gleichzeitig wird aber auch die Referenz von meinem GUI auf das Repo weggenommen und dann beißt sich die Katze in den Schwanz. Dadurch dass es nun keine Referenz mehr auf das GUI gibt, wird dieses auch automatisch zerstört.
Der Destructor wird also direkt ein 2x aufgerufen, was natürlich dann in einer neuen Exception endet, weil die Sachen ja bereits zum Teil zerstört wurden.

Kurz zum normalen Ablauf, falls sich der Leser fragt, wie ich das denn sonst freigebe ohne Probleme:
Im normalen Ablauf sagt die GUI-Steuerung dem GUI-Fenster per Event dass es geschlossen wird.
Es wird also ein OnBeforeClose-Event ausgelöst. In diesem Event löse ich die Referenz vom GUI-Fenster zum Repo
mittels eines Detach auf, außerdem werden noch auf Änderungen geprüft, Verbindungen getrennt, etc. Dann löst die Steuerung die letzte Referenz auf und das GUI-Fenster wird zerstört.
Der Destructor vom GUI-Fenster wird also niemals von mir per Free direkt aufgerufen, sondern nur, wenn es keine Referenzen mehr gibt und auch nur über eine Steuerung.

Wie umgehe ich das Problem? Oder was muss ich ändern, damit es nicht passiert?
Lässt sich das überhaupt umgehen ohne sehr große Designänderung?

Klar ich kann es so programmieren und testen, dass im Konstruktor absolut nix schief gehen kann, aber dass kann es ja bekanntlich immer. Ich will es nur robuster machen.
Im Grunde will ich den automatischen Destructoraufruf bei der Exception unterbinden. Da ich die Exception abfange will ich vorher die Referenzen wegnehmen, damit der Destructor dann sauber durchläuft.

[Uwe Raabe]

Ich hätte vor dem FRepo := nil; etwas wie FRepo.Detach(Self); erwartet.

[Uwe Raabe]

Und zeig doch mal, was TGuiInterfaceBase ist.

Vielleicht kannst du das Problem auch damit lösen, daß du die Methode BeforeDestruction überschreibst und dort den Referenzzähler um 1 hochsetzt:

Delphi-Quellcode:

procedure TGUIFenster.BeforeDestruction;
begin
  inherited;
  Inc(FRefCount); // oder was thread-sicheres
end;

Den gleichen Mechanismus setzt Delphi selbst auch beim Create in TInterfacedObject ein (siehe NewInstance und AfterConstruction ).

[ColeZero]

Zitat von Uwe Raabe:

Ich hätte vor dem FRepo := nil; etwas wie FRepo.Detach(Self); erwartet.

Hallo Danke für die Antwort

Das würde leider nicht viel helfen, denn dann würde der Destructor nicht mehr an der Stelle FRepo := nil; ein zweites mal aufgerufen, sondern schon an der Stelle FRepo.Detach(Self); sobald es eine Exception im Constructor gibt.
Das Problem bleibt bestehen

Für den normalen Ablauf würde es mir auch nichts helfen, denn das GUI-Fenster soll erst zerstört werden, wenn es keinerlei Referenzen auf das Fenster mehr gibt bzw. das Fenster nirgendswo mehr registriert ist.
FRepo.Detach(Self); muss vor dem Destructor aufgerufen werden, damit der Destructor überhaupt aufgerufen werden kann. Denn im Destructor bringt es mir nichts, da der Destructor niemals aufgerufen wird, wenn es noch eine Referenz gibt.

Zitat von Uwe Raabe:

Und zeig doch mal, was TGuiInterfaceBase ist.

Vielleicht kannst du das Problem auch damit lösen, daß du die Methode BeforeDestruction überschreibst und dort den Referenzzähler um 1 hochsetzt:

Delphi-Quellcode:

procedure TGUIFenster.BeforeDestruction;
begin
  inherited;
  Inc(FRefCount); // oder was thread-sicheres
end;

Den gleichen Mechanismus setzt Delphi selbst auch beim Create in TInterfacedObject ein (siehe NewInstance und AfterConstruction ).

Ja daran habe ich jetzt auch gedacht, dass ich die automatische Referenzzählung ausschalte und selber zähle. Nur das würde mir wahrscheinlich nicht viel helfen.

Wenn ich den Zähler selber um einen erhöhe, dann müsste ich ja Problem im normalen Ablauf haben, wenn es keine Exception gibt. Dann ist der Counter ja eine Zählung zu hoch, weswegen das GUI-Fenster nicht zerstört werden würde, oder?

Das TGuiInterfaceBase ist nur eine Basisklasse von einem TFrame die eine Schnittstelle implementiert, mit einigen Funktionen die alle GUI-Fenster(Frames) haben sollen ohne sie jedesmal neu zu programmieren, unter anderem gibt es da auch die Referenzzählung, welche identisch ist mit der TInterfaced-Zählung.

[Uwe Raabe]

Zitat von ColeZero:

Ja daran habe ich jetzt auch gedacht, dass ich die automatische Referenzzählung ausschalte und selber zähle. Nur das würde mir wahrscheinlich nicht viel helfen.

Wenn ich den Zähler selber um einen erhöhe, dann müsste ich ja Problem im normalen Ablauf haben, wenn es keine Exception gibt. Dann ist der Counter ja eine Zählung zu hoch, weswegen das GUI-Fenster nicht zerstört werden würde, oder?

Das BeforeDestruction wird automagisch vor dem Aufruf der vererbten Destroy-Kette aufgerufen. Mit meinem Vorschlag ersetzt du nicht generell die Referenzzählung, sondern schaltest sie nur während des Destroy aus. Wenn im Constructor keine Exception ausgelöst wird, wird auch kein Destroy aufgerufen und somit das BeforeDestruction auch nicht - alles läuft wie gehabt.

[ColeZero]

Zitat von Uwe Raabe:

Das BeforeDestruction wird automagisch vor dem Aufruf der vererbten Destroy-Kette aufgerufen. Mit meinem Vorschlag ersetzt du nicht generell die Referenzzählung, sondern schaltest sie nur während des Destroy aus. Wenn im Constructor keine Exception ausgelöst wird, wird auch kein Destroy aufgerufen und somit das BeforeDestruction auch nicht - alles läuft wie gehabt.

Okay das probiere ich mal aus. Vielen Dank für die Info!

[Blup]

Alternativ kann man den Referenzzähler (FRefCount) auch gleich auf 0 setzen.

[Uwe Raabe]

Zitat von Blup:

Alternativ kann man den Referenzzähler (FRefCount) auch gleich auf 0 setzen.

Das kann aber auch schief gehen. Wenn nämlich im Destroy die Instanz als Interface-Referenz verwendet wird, die wiederum eine Referenzzählung auslöst, wird mit dem _AddRef/_Release womöglich noch ein Free aufgerufen. Das gilt übrigens immer bei Abkömmlingen von TInterfacedObject und nicht nur in diesem Fall. Warum dieser Fall im constructor berücksichtigt wird, im destructor aber nicht, bleibt ein Rätsel. Ein diesbezüglicher QC-Eintrag von mir bereits für Delphi 2007 ist immer noch Open. In der VCL kommt das Problem offenbar nicht vor.