aus einer Liste Einträge in eine andere Liste verschieben

[Sir Rufo]

Damit es auch hier steht

Delphi-Quellcode:

procedure fooOne;
var
  bar : TBar;
begin
  bar := TBar.Create;
  try
    // work on bar
  finally
    bar.Free;
  end;
end;

// aber nicht so

procedure fooNleaks;
var
  bar1 : TBar1;
  bar2 : TBar2;
begin
  bar1 := TBar1.Create;
  // wenn jetzt eine Exception ausgelöst wird, dann wird bar1 niemals entfernt!
  bar2 := TBar2.Create;
  try
    // work on bars
  finally
    bar1.Free;
    bar2.Free;
  end;
end;

// darum so

procedure fooNsafe;
var
  bar1 : TBar1;
  bar2 : TBar2;
begin
  // lokale Variablen sind NICHT initialisiert, darum auf NIL setzen!
  bar1 := nil;
  bar2 := nil;
  try
    bar1 := TBar1.Create;
    // wenn jetzt eine Exception ausgelöst wird, dann wird bar1 korrekt entfernt!
    bar2 := TBar2.Create;
    // work on bars
  finally
    bar1.Free;
    bar2.Free;
  end;
end;

[DeddyH]

Und damit es auch komplett hier steht, die Alternative:

Delphi-Quellcode:

procedure fooNsafe;
var
  bar1 : TBar1;
  bar2 : TBar2;
begin
  //Verschachteln der Ressourcenschutzblöcke
  bar1 := TBar1.Create;
  try
    bar2 := TBar2.Create;
    try
      // work on bars
    finally
      bar2.Free;
    end;
  finally
    bar1.Free;    
  end;
end;

[Sir Rufo]

@DeddyH

Wer macht denn sowas?

Ja geht auch, aber mir ist das zu verschachtelt und zuviel Tipparbeit ... nix für faule Leute wie mich

[DeddyH]

Wenn es nur 2 Blöcke sind, mache ich das schon. Sollten es mehr sein, tut die Methode wahrscheinlich sowieso schon zu viel, ist also ein Fall für die Auslagerung

[Aviator]

Danke für die Info. So habe ich das zwar noch nicht gesehen, aber bei mir kommt es nicht so oft vor, dass mehrere Creates hintereinander ausgeführt werden.

[Mavarik]

Zitat von Sir Rufo:

@
Ja geht auch, aber mir ist das zu verschachtelt und zuviel Tipparbeit ... nix für faule Leute wie mich

hmm...

Delphi-Quellcode:

var
  IBar1 : TBar1Intf;
  IBar2 : TBar2Intf;
begin
  IBar1 := TBar1Impl.Create;
  IBar2 := TBar2Impl.Create;
  // work on iBar's
end;

[Bjoerk]

TBar1Intf, TBar2Intf, TBar1Impl, TBar2Impl: Qu'est-ce que c'est?

[Sir Rufo]

Bei einem Interface mit Referenzzählung braucht man auch nicht freigeben.

Und benennen kann man die, wie man will, ein I statt einem T ist ratsam aber nicht Pflicht

[DeddyH]

Zitat von Sir Rufo:

Bei einem Interface mit Referenzzählung braucht man auch nicht freigeben.

Stimmt, aber wenn die Implementationen von TInterfacedPersistent abstammen, ist der gezeigte Code wieder für's Gesäß. Außerdem finde ich es fragwürdig, Interfaces als Ersatz für Garbage Collection zu benutzen.

[Bjoerk]

Ok. Mit interfaces arbeite ich eh nie (keinen Plan). Würde mal sagen, bei Klassen hängt's auch davon ab, was im constructor so passiert. Ein TObject.Create wird wohl nicht wahnsinnig viele Exceptions werfen? Dennoch, ich stimme #14 voll und ganz zu und so hatte ich's ja auch gemacht.