Wieso Speicheranforderung in Try...Finally ?

[Bbommel]

Zitat von DeddyH:

Zitat von Bbommel:

Als Argument für try/finally wird immer wieder geschrieben, dass es das Programm robuster machen würde, weil so auch unerwartete Fehler behandelt würden.

Quellen?

Na, dieser Thread. So hab ich hier die Hauptargumente für das try/finally jedenfalls verstanden: Auch im Fehlerfall werden die Ressourcen noch sauber freigegeben => das Programm wird robuster. Das Wort robuster schwirrte mir im Kopf rum, weil es HeZa in Beitrag #13 benutzt hat. Passt aber ganz gut zu dem, wie ich die Pro-Argumente bisher verstanden habe.

Bis denn
Bommel

[DeddyH]

Ich meinte Quellen für den 2. Teil: unerwartete Fehler werden nur bei try-finally behandelt (zumindest habe ich das so rausgelesen).

[Bbommel]

Ähm, nee, so war das nicht gemeint... Kann man das so lesen? Hmmm... ungeschickt formuliert vielleicht. Streiche das "so auch"...

[stahli]

Dann sehe ich das exakt genau wie Du.

[Luckie]

Dass try-finally Fehler behandelt ist falsch. try-finally ist ein Ressourcenschutzblock und auch im Fehlerfall belegte Ressourcen wieder frei zu geben. Eine Fehlerbehandlung findet im Except-Block statt.

[DeddyH]

Sagen wir das nicht die ganze Zeit?

[Luckie]

Wir ja, aber stahli in seinem letzten Posting nicht.

Und ein Ressourcenschutzblock macht eine Anwendung in sofern robuster, dass in einem Fehlerfall der Speicher nicht zu läuft. Nehmen wir an man bearbeitet in einer Schleife hunderte von Objekten (Bilder zum Beispiel). Jetzt kommt es bei mehreren Bildern zu Fehlern, warum auch immer. Habe ich jetzt keinen Ressourcenschutzblock, würde der allozierte Speicher nicht mehr freigegeben. Und das kann durch aus zu kritischen Situationen führen. Oder anderes Beispiel: Ich schreibe ein Programm welches Ressourcen benötigt, die nicht immer unbedingt verfügbar sind, weil der Server weggebrochen ist. Da haben wir wieder das gleiche Problem. Nicht immer muss ein Programm unbrauchbar sein, wenn mal eine Ressource nicht zur Verfügung steht.

[DeddyH]

Quizfrage: wird Test freigegeben?

Delphi-Quellcode:

type
  TTest = class
  public
    procedure DoWork;
  end;

procedure TTest.DoWork;
begin
  raise Exception.Create('Kabumm');
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  Test: TTest;
begin
  Test := TTest.Create;
  try
    Test.DoWork;
  except
    on E: Exception do
      begin
        ShowMessage('Irgendeine Fehlerbehandlung');
        raise;
      end;
  end;
  Test.Free;
end;

[Bbommel]

Nein, wird es nicht, deswegen hatte ich ja auch geschrieben, dass man bei einem re-raise der Exception mit verschachteltem try-except-try-finally arbeiten müsse. Ohne das erneute raise würde es aber freigegeben.

[DeddyH]

Richtig. Stellen wir uns nun vor, wir haben eine Klasse mit so einer Methode drin (sagen wir ca. 20 LOC). Irgendwann denken wir uns, dass es evtl. ganz gut wäre, die Exception durchzureichen. Gesagt, getan, ein "raise" ans Ende des Except-Blocks und fertig. Schon haben wir uns Platz für ein Speicherleck geschaffen und merken es nicht bzw. können uns nicht erklären, wo es herkommt. Zumindest ich würde nicht als Erstes daran denken, noch einen try-finally-Block drumherum zu schreiben, schließlich war das Leck vorher ja auch nicht da. Und nun erteile ich der anderen Partei das Wort, die finally aus Übersichtlichkeitsgründen weglässt.