Zwei Objekte in einem oder zwei Try Finaly Blöcke?

[DeddyH]

Meiner Meinung nach ja. Exceptions sind doch nichts Böses, soll man bei jedem Auftreten einer solchen das Programm neu starten? Oder einfach warten, bis der Speicher vollgelaufen ist?

[stahli]

Aber es geht doch hier offensichtlich um keine erwarteten Probleme.

Wenn ich eine Ini einlesen will und das Laufwerk existiert nicht, dann muss ich das berücksichtigen und das Problem behandeln (z.B. Standardwerte benutzen oder Hinweise ausgeben oder Programmteile sperren oder was auch immer).
Alles super. Es gibt verschiedene Wege. Den normalen Weg und in bestimmten Fällen Alternativen. Das Programm arbeitet wie vorgesehen.

Wenn aber TPanel.Create nicht funktioniert (warum auch immer - Speicher defekt, Virus, "Beta-Bugfix" vom Hersteller oder falsche Mondphase) dann bringt es nichts, das aufrufende Formular mit Free freizugeben.
Das Programm ist nicht funktionsfähig und muss schnellstens repariert werden.
Wenn der Kunde das Formular 1000 mal startet wird zwar der Speicher nicht so schön aufgeräumt wie mit finally aber da kommt es dann doch wirklich nicht mehr drauf an.
Mit Daten-Objekten wäre diese stillschweigende Fehlerunterdrückung noch schlimmer, da der User dann u.U. gar nicht merkt, dass irgendwas nicht funktioniert.

[DeddyH]

Irgendwie habe ich das Gefühl, dass Du finally mit except verwechselst.

[stahli]

Glaube ich eigentlich nicht.
Der finally- Block wird in jedem Fall ausgeführt, auch wenn es in try knallt. Richtig?
Aber die erwartete Überweisung wird nicht durchgeführt und es erfolgt kein Fehlerhinweis.

--> oder unterdrückt finally die Fehlermeldung nicht - dann läge ich tatsächlich falsch

Aber selbst dann würde ich solch ein Konstrukt nur für sinnvoll halten, wenn ein Problem an der Stelle zumindest denkbar ist.

Delphi-Quellcode:

B := nil;
A := TMyClass.Create;
try
    B := TMyClass.Create; // wenn es hier knallt geht es nach finally weiter, die Überweisung wird aber nicht ausgeführt und keiner kriegt es mit
    EuroÜberweisenVonStahliZuHimi(B.Value);
finally
    A.Free; 
    B.Free;
end;

[DeddyH]

Zitat von stahli:

--> oder unterdrückt finally die Fehlermeldung nicht - dann läge ich tatsächlich falsch

Einfach mal ausprobieren

Delphi-Quellcode:

procedure TFormTrallalla.ButtonBummsClick(Sender: TObject);
var
  Dings: TStringlist;
begin
  Dings := TStringlist.Create;
  try
    Dings.Add('Wuppdi');
    ShowMessage(Dings[1]);
  finally
    Dings.Free;
  end;
end;

Ohne Debugger starten und schauen, ob da eine Meldung kommt.

[stahli]

[OT] Kann ich erst später, sonst hätte ich natürlich nicht gefragt. [/OT]

[DeddyH]

Dann sage ich es Dir einfach: es kommt eine Meldung "Listenindex überschreitet das Maximum(0)". Finally fängt eben keine Fehler ab, dazu ist except da, sondern wird nur garantiert durchlaufen, sobald man den dazugehörigen try-Block betreten hat. Man nennt dieses Konstrukt daher ja auch Ressourcenschutzblock.

[Popov]

@stahli

Vielleicht bringe ich mal einen anderen Betrachtungspunkt in das Spiel. Ein Beispiel:

Delphi-Quellcode:

type
  TTest = class
  public
    constructor Create;
  end;

constructor TTest.Create;
begin
  raise Exception.Create('Fehler');
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  Test: TTest;
begin
  Test := TTest.Create;
  try
    ShowMessage('Im Try');
    Abort;
  finally
    ShowMessage('Im Finally');
    Test.Free;
  end;
end;

In Create wird eine Exception ausgelöst. Hier ist es unwichtig ob es einen Try Finally oder gar Try Exception Block gibt. Der kommt erst gar nicht ins Spiel. Macht es in Create Krachbumm, wird der Fehler intern abgewickelt, bzw. es geht intern sofort zum Destructor. Try Finally ist für Fehler gedacht die später kommen.

[HeZa]

@stahli

ein finally verschluckt keine Exception!

Delphi-Quellcode:

sl := TStringlist.Create;
try
  raise Exception.Create('No chance');
finally
  sl.Free;
end;

sl.Free wird, wie du ja gesagt hast immer ausgeführt. Wenn finally ausgeführt wird, während eine Exception läuft, wird nach der Ausführung des finally-Bolcks, die Exception trotzdem weiter geworfen.

Mit anderen Worten: Finally schützt deine Resourcen, erlöst dich aber nicht von der Exception.

[Uwe Raabe]

Zitat von stahli:

Wenn Du als Nutzer obiges Programm ausführst und B.Create knallt - warum auch immer - wirst Du mit dem Programm nicht glücklich werden.
Ob da noch Speicher allociert ist oder nicht, wäre da nebensächlich.

Du erfährst als Nutzer nicht, dass die Überweisung nicht funktioniert hat.
Ok, es wird kein Speicher verschwendet aber das ist doch sowas von egal.

Besser wäre, wenn es eine Fehlermeldung gibt. Entweder eine Schutzverletzung oder eine nette Erklärung wie "Die Überweisung konnte nicht durchgeführt werden!".
In jedem Fall muss die Software gefixt (oder einer neue Version verkauft ) werden.

Natürlich sollte man einen Fehler bei der Überweisung abfangen und entsprechend reagieren. Es könnte ja ganz einfach sein, daß das Konto nicht gedeckt ist. Dann hilft auch eine neue Programmversion nicht weiter, da die Software ja nicht die Ursache des Fehlers ist.

Es könnte aber sein, daß TMyClass irgendwelche Resourcen anfordert (z.B. eine Verbindung zum Bankrechner), die es im Destruktor wieder freigibt. Dann sollte das finally aber ganz sicher durchlaufen werden. Es ist dabei sogar möglich, daß im Destroy eine Exception geworfen wird, die darauf hinweist, daß z.B. diese Verbindung nicht sauber geschlossen werden konnte. Also können auch Aufrufe wie B.Free noch eine Exception werfen. Nicht immer hat man auch die Kontrolle über diese Klassen, wenn die z.B. aus einer Bibliothek kommen.

Ich würde mich also in keinem Fall darauf verlassen, daß ein Create oder Destroy schon keine Exception auslöst.