Prüfung auf Assigned(MyObject) true obwohl MyObject nicht initialisiert wurde

[freejay]

Zitat von haentschman:

Hallöle...

Besser...

Delphi-Quellcode:

procedure TfMain.Button1Click(Sender: TObject);
var
  In_A: string;
  slShow: TStringList;
begin
  In_A := '';

  slShow := TStringList.Create; 
  try
    if In_A = '' then
      exit;
     
  finally
    slShow.Free;
  end;
end;

Danke! Da hast Du natürlich recht: So setze ich es jetzt auch in meinen echten Projekten um...

[Uwe Raabe]

Wobei die Initialisierung von In_A streng genommen redundant ist, da strings als managed type automatisch initialisiert wird. Der Lesbarkeit halber würde ich das aber schon so lassen.

Zitat von Bernhard Geyer:

Sollte es hier nicht eine Compilerwarnung geben?
Die Zeile "slShow := TStringList.Create;" sollte vor dem try stehen.

Nein, das ist durchaus ein gängiges Muster und erst recht vom Compiler nicht zu beanstanden.

[Schokohase]

Zitat von Uwe Raabe:

Zitat von Bernhard Geyer:

Sollte es hier nicht eine Compilerwarnung geben?
Die Zeile "slShow := TStringList.Create;" sollte vor dem try stehen.

Nein, das ist durchaus ein gängiges Muster und erst recht vom Compiler nicht zu beanstanden.

Beispiel:

Delphi-Quellcode:

procedure foo;
var
  sl1, sl2: TStringList;
begin
  sl1 := nil;
  sl2 := nil;
  try

    // beliebiger code hier

    sl1 := TStringList.Create;

    // beliebiger code hier

    sl2 := TStringList.Create;

    // beliebiger code hier

  finally
    sl1.Free;
    sl2.Free;
  end;
end;

Wenn an irgendeiner Stelle von "beliebiger code hier" eine Exception geworfen wird, oder mit Exit der Code verlassen werden soll, dann wird der finally-Block ohne Probleme abgearbeitet.

[Dennis07]

Das Problem wird nur sein, dass du dann nicht mehr den ursprünglichen Fehler mittels Exception-Handling abfangen kannst, weil du dann im finally -Abschnitt eine Access-Violation bekommst.
Auch geht das so nur bei objekten, die nicht voneinander abhängig sind.

[Schokohase]

Zitat von Dennis07:

Das Problem wird nur sein, dass du dann nicht mehr den ursprünglichen Fehler mittels Exception-Handling abfangen kannst, weil du dann im finally -Abschnitt eine Access-Violation bekommst.

Probier es aus, so gibt es eben kein Problem und die Exceptions funktionieren wunderbar.

BTW: Du weißt, dass die Methode Free auf nil prüft bevor diese den Destructor aufruft? Also davon kann es keine AV geben.

Zitat von Dennis07:

Auch geht das so nur bei objekten, die nicht voneinander abhängig sind.

Dann muss man eigentlich nur auf die Reihenfolge bei der Freigabe achten (oder darf gar nicht freigeben, wenn man das Lifetime-Management delegiert habe)

[freimatz]

Puh, da ist einiges falsch.

Das Create gehört vor den try.

Dass das obige "sl1.Free;" funktioniert, liegt vielleicht nur daran, dass bei TStringList zufällig nichts schlimmes passiert.
Free ruft Destroy() auf und wenn dort auf Felder zugegriffen wird, dann gibt es zwangsläufig eine Schutzverletzung.
Wenn bei obigem "// beliebiger code hier" eine Exception passiert, dann bleibt sl1 nil

"Dass die Methode Free auf nil prüft" ist auch falsch. FreeAndNil prüft dagegen.

[Uwe Raabe]

Zitat von freimatz:

"Dass die Methode Free auf nil prüft" ist auch falsch. FreeAndNil prüft dagegen.

Du irrst gewaltig! In beiden Fällen!

Delphi-Quellcode:

procedure TObject.Free;
begin
// under ARC, this method isn't actually called since the compiler translates
// the call to be a mere nil assignment to the instance variable, which then calls _InstClear
{$IFNDEF AUTOREFCOUNT}
  if Self <> nil then
    Destroy;
{$ENDIF}
end;

Delphi-Quellcode:

procedure FreeAndNil(var Obj);
{$IF not Defined(AUTOREFCOUNT)}
var
  Temp: TObject;
begin
  Temp := TObject(Obj);
  Pointer(Obj) := nil;
  Temp.Free;
end;
{$ELSE}
begin
  TObject(Obj) := nil;
end;
{$ENDIF}

[Schokohase]

Zitat von freimatz:

Puh, da ist einiges falsch.

Das Create gehört vor den try.

Dass das obige "sl1.Free;" funktioniert, liegt vielleicht nur daran, dass bei TStringList zufällig nichts schlimmes passiert.
Free ruft Destroy() auf und wenn dort auf Felder zugegriffen wird, dann gibt es zwangsläufig eine Schutzverletzung.
Wenn bei obigem "// beliebiger code hier" eine Exception passiert, dann bleibt sl1 nil

"Dass die Methode Free auf nil prüft" ist auch falsch. FreeAndNil prüft dagegen.

Bitte, erst informieren, dann dementieren.

Das Create kann stehen wo will.

Delphi-Quellcode:

var
  f: TObject;
begin
  f := TObject.Create;
  try

  finally
    f.Free;
  end;
end;

oder

Delphi-Quellcode:

var
  f: TObject;
begin
  f := nil;
  try
    f := TObject.Create;

  finally
    f.Free;
  end;
end;

Ist beides gleichwertig. Die zweite Variante macht allerdings nur dann richtig Sinn, wenn man mehrere Instanzen mit einem Resourcen-Schutzblock absichern kann/will.

Das mit dem Free und nil hat Uwe ja schon erklärt.

Manchmal ist Erkenntnis nur einen Klick entfernt und da wundert man sich halt schon manchmal über das was hier an Wissen offenbart wird.

[freimatz]

Dazu gibt es ja zum Glück das Forum.
Asche auf mein Haupt. Tut mir leid.
Ich war mir so sicher ... War das schon immer so?

Lustig: Habe nach "procedure TObject.Free;" bei mir gesucht und gefunden:

Delphi-Quellcode:

procedure TObject.Free;
begin
  Dispose(PObject(@Self), Done);
end;

Allerdings stand oben drin "Turbo Pascal Version 7.0"

[dummzeuch]

Zitat von freejay:

Zitat von haentschman:

Besser...

Delphi-Quellcode:

procedure TfMain.Button1Click(Sender: TObject);
var
  In_A: string;
  slShow: TStringList;
begin
  In_A := '';

  slShow := TStringList.Create; 
  try
    if In_A = '' then
      exit;
     
  finally
    slShow.Free;
  end;
end;

Danke! Da hast Du natürlich recht: So setze ich es jetzt auch in meinen echten Projekten um...

Naja, das ist zwar nicht falsch, erzeugt aber, wenn In_A = '', unnötigerweise die Stringlist, nur um sie dann sofort wieder freizugeben. Bei einer Stringlist ist das noch relativ egal, aber bei komplexeren Klassen kann der Constructor schonmal einiges an Ressource fressen, so dass man sie nur erzeugen sollte, wenn wirklich notwendig. Die Variante mit slShow := nil vor dem Try ist in dem Fall dann besser.