Function Result

[himitsu]

@mjustin: dann kannst du das Try-Finally auch gleich mit rausürzen ... bei 'ner Exception geht es doch sowieso nach dem END weiter

Delphi-Quellcode:

function abc: Boolean;
var
  Obj: TObject;
begin
  Result := False;
  Obj := TObject.Create;
  try
    // etwas das schiefgehen kann ...
    ...
    // hat funktioniert:
    Result := True;
  except
    // behandeln
  end;
  Obj.Free;
end;

[omata]

Ja, nur jetzt wird Obj bei einer Exeption nicht mehr freigegeben.

[himitsu]

doch, wird es :angel: ... kannst's gern ausprobieren

Delphi-Quellcode:

function abc: Boolean;
var
  Obj: TObject;
begin
  Result := False;
  Obj := TObject.Create;
  ShowMessage('Obj := TObject.Create;');
  try
    // etwas das schiefgehen kann ...
    // ...
    Raise Exception.Create('123');

    // hat funktioniert:
    Result := True;
    ShowMessage('Result := True;');
  except
    ShowMessage('except');
  end;
  Obj.Free;
  ShowMessage('Obj.Free;');
end;

Nach einem Try-Except-Block wird "IMMER" weitergearbeitet.
Und selbst wenn da mal so ein großer Fehler auftritt, daß selbst Try-Except ihn nicht behandeln könnte, dann würde auch Try-Finally versagen.

[omata]

Ok, hast recht. Die Exception wird ja behandelt, danach geht es dann normal weiter.

[Apollonius]

Das Finally braucht man allerdings, wenn man einen Exception Filter einbaut. Und das sollte man tun, um System-Exceptions durchzulassen.

[mjustin]

Delphi-Quellcode:

function abc: Boolean;
var
  Obj: TObject;
begin
  Result := False;
  Obj := TObject.Create;
  try
    // etwas das schiefgehen kann ...
    // ...
    // hat funktioniert:
    Result := True;
  except
    begin
      ShowMessage('except und bye bye');
      raise;
    end; 
  end;
  Obj.Free; // wird bei Exception nicht mehr erreicht
end;

Wenn man z.B. ein raise im Exceptionhandler hat wie in diesem Beispiel, wird das Objekt beim Auftreten einer Exception nicht mehr freigeben. Daher verwende ich immer das "try .. finally .. Obj.Free .. end" Muster.

[himitsu]

OK, wenn du die Exception duchläßt dann nimmer, aber wenn man die exception abgefangen hat, kann man die doch auch behandeln (selbst wenn es 'ne "System"-xception ist) ... oder wollt ihr den Programmvortlauf durch die Exception steuern/abbrechen lassen? :shock:

[Apollonius]

Solche Schätzchen wie Stack Overflows, Out-Of-Memory-Exceptions o.Ä. lassen sich schwerlich behandeln. Es ist so ziemlich das Dümmste, was man tun kann, solche Exceptions abzufangen und dann ohne Meldung oder mit einer in der Art von "Datei konnte nicht gefunden werden" weiterzulaufen. In den allermeisten Fällen gibt es abgesehen von einem Absturz mit einer aussagekräftigen Meldung einfach nichts zu tun.

[mjustin]

Zitat:

Zitat von himitsu

OK, wenn du die Exception duchläßt dann nimmer, aber wenn man die exception abgefangen hat, kann man die doch auch behandeln (selbst wenn es 'ne "System"-xception ist) ... oder wollt ihr den Programmvortlauf durch die Exception steuern/abbrechen lassen? :shock:

Eine spannende Frage hierbei ist: kann man eigentlich in einer Funktion sowohl eine Exception auslösen, als auch ein Funktionsergebnis zurückliefern, anders gefragt: hat der aufrufende Code überhaupt eine Chance, das Funktionsergebnis zu erhalten, wenn in der Funktion eine Exception geworfen (und nicht behandelt) wird?

Beispiel:

Delphi-Quellcode:

try
  X := ThrowsException(Y);
finally
  // behandle Exception ...
end;

ComputeSomething(X);

Wird der Variable X noch der Funktionswert zugewiesen, der in der Methode ThrowsException (vor einem raise) dem Result zugewiesen wurde, bevor zum finally gesprungen wird? Oder ist der Wert von X beim Aufruf von ComputeSomething undefiniert?

[Apollonius]

Das hängt vom Typen ab. Bei intern als Out-Parametern zurückgegebenen Typen, d.h. Records, Arrays, Interfaces, Strings und Variants, kommt ein gültiges Resultat zustande. Bei allen anderen Typen nicht.