"FinalllyExit" gewünscht

[stahli]

Ich würde mir folgende Delphi-Syntax wünschen:

Delphi-Quellcode:

function MyFunc(var Counter: Integer): Real;
var
  O: TMyObject;
begin
  O := TMyObject.Create;
  O.MachWas(Counter);
  if (O.Dies) then
    Exit(Random)
  else
  if (O.Das) then
    Exit(0);
  Result := 1 / 0; // Exception
FinallyExit: // <-- Vor dem Aussprung IMMER ausführen, was folgt
  FreeAndNil(O);
  Inc(Counter);
end;

Es geht mir hier nur darum, dass vor dem Aussprung aus der Funktion IMMER noch irgend etwas erledigt wird.
FinallyExit könnte also ein automatisches GoTo-Label implemententieren, so dass auch Exit dort hin führt.
Ebenso könnte dieses Konstrukt als Try-Finally-Block fungieren.

Um das zu erzielende Ergebnis umzusetzen, müsste man bisher einen Try-Finally-Block definieren und die Exit-Anweisungen durch GoTo ersetzen, wobei hier zuvor noch Result zugewiesen werden müsste.
Ich habe mir eine solche Syntax schon öfters gewünscht.

Was haltet Ihr davon?

[Neutral General]

Schonmal ausprobiert?

exit springt innerhalb eines try-finally-Blocks in den finally-Block

[jfheins]

Überflüssig.

Exakt diese Funktionalität wird bereits durch try-finally abgedeckt. Falls du das nicht glaubst, zeige bitte ein Stück Code wo das finally nicht ausgeführt wird

[stahli]

Ok danke. Klar glaube ich Euch das, aber ich wusste das nicht.

Ich arbeite selten mit try-Blöcken.
Ich hatte beim programmieren lernen gelesen, dass man try-Blöcke (nur) verwendet, um Fehlermeldungen bei erwarteten (und zu tolerierenden) Fehlern zu unterdrücken.
Also z.B. bei I/O-Funktionen.

Das steckt halt so drin. Aber ich werde mir das noch mal genauer ansehen...

Danke!

[himitsu]

Try-Except = auf Fehler (Exceptions) reagieren ... fast so, wie du es gelernt hast

Try-Finally = immer einen bestimmten AufräumCode ausführen, egal was passiert



Aber nicht "unterdrücken", sondern behandeln.

[Zacherl]

Eine wichtige und immer wiederkehrende Funktion von try Blöcken ist neben dem Behandeln von Exceptions auch beispielsweise das sichere Freigeben von Resourcen:

Delphi-Quellcode:

MyObject := TObject.Create;
try
  MyObject.DoSomething;
finally
  MyObject.Free;
end;

[stahli]

Na ja, grundsätzlich sind mir die Fehlerbehandlungen schon klar.

Nur, wenn es irgendwo knallt, ist es m.E. zweitrangig, ein erzeugtes Objekt auch wieder frei zu geben.
Jedenfalls nicht, wenn nicht innerhalb der Fehlerbehandlung selbst wieder ein konstistenter Projektzustand hergestellt wird.

Wenn Exit in einem Try-Block in finally springt, ist das schon mal eine Lösung, aber nicht wirklich das, was ich erwartet habe.

Mal ein Beispiel (ungetestet, nur Resultat Eurer Erklärungen):

Delphi-Quellcode:

function MyFunc: Real;
var
  O: TMyObject;
begin
  O := TMyObject.Create;
  try
    O.DoA;
    if O.A then 
      Exit(-1); // ist kein Exit sondern springt in finally - DoNotIfExitBefore wird noch bearbeitet, das wäre ohne Try-Block nicht der Fall, da würde die Funktion VERLASSEN
    O.DoB;
    Result := 1 / 0; // Exception -> Sprung nach finally
    O.DoC;
    Result := O.Result;
  finally
    O.Free;
  end;
  DoNotIfExitBefore; // wird trotz EXIT ausgeführt
end;

Nach Eurer Beschreibung reagiert Exit nicht mehr "normal", wenn man es (z.B. nachträglich) in einen Try-Block kapselt.
Zumindest muss man darauf wohl unbedingt achten, da Exit dann nicht wirklich die Funktion verlässt.

Manchmal möchte man ja eine Funktion unter bestimmten Bedingungen gar nicht ausführen. Wenn man dann das Exit in ein Try-Block aufnimmt, nach dessem finally-end noch etwas ausgeführt wird, dann funktioniert das Exit nicht erwartungsgemäß.

Und zur Objektfreigabe: Wenn im obigen Fall O.DoC nicht mehr ausgeführt wird und man den Fehler nachträglich nicht (durch eine Neuberechnung o.ä. korrigiert) bringt einen die Objektfreigabe auch nicht wirklich weiter. Das Projekt arbeitet fehlerhaft bzw. nicht zuverlässig. Der Fehler muss UNBEDINGT bereinigt werden, aber die Freigabe des Objektes finde ich im Fehlerfall mindestens nachranging.
Ob das Objekt nun aufgelöst wird oder nicht - das Programm beinhaltet fehlerhafte Daten. Die Funktion muss angepasst werden und eine "drohende" Division durch Null selbständig behandeln.

Aber ich schaue mir die ganze Try-Geschichte natürlich nochmal an.

[Zacherl]

Zur not könntest du dich mit einer Hilfsvariable, die du sagen wir nach dem Exit Befehl auf true setzt aus der Afäre ziehen. Dann checkst du nach dem finally, ob die Variable gesetzt ist und führst nur dann eventuelle weitere Funktionen aus. Guter Stil ist das denke ich allerdings nicht ..

[himitsu]

Zitat:

// wird trotz EXIT ausgeführt

Nur wenn vorher keine Exception auftrat.

Exit springt aus der Prozedur, aber vorher werden noch die Finally-Abschnitte der umgebenden Try-Finally abgearbeitet.


Bei Try-Except wird, wenn in dem Except-Teil keine neue Exceptions ausgelöst oder die alte Exception weitergeeicht wird, der nachfolgende Code ausgeführt, da die Exception ja abgefangen wurde.

Zitat:

Der Fehler muss UNBEDINGT bereinigt werden

Und dafür ist Try-Finally/Except da, daß man auf "Außnahmen" reagieren kann und dieses entsprechend behandelt.
Dieses kann aber auch bedeuten, daß man noch schnell eine ordentliche Fehlermeldung ausgibt und dann das Programm gezielt und ordnungsgemäß beendet.

[stahli]

Ok, das (finally und DANN exit) hört sich sehr gut an. Ich schaue mir das wie gesagt noch genau an.

Danke!


PS: In meinem Beispiel ist natürlich klar, dass O vor dem Exit freizugeben wäre. Da war ich etwas zu hektisch. Sorry.