"FinalllyExit" gewünscht

[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 ..

[jfheins]

Zitat von stahli:

Nur, wenn es irgendwo knallt, ist es m.E. zweitrangig, ein erzeugtes Objekt auch wieder frei zu geben.

[...]

... 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.

Naja, so kann man das nicht sagen. Nimm an, es geht um einen Filestream und du möchtest Daten speichern. Ohne Exceptionhandling. Es tritt ein Fehler auf, der an den benutzer weitergegeben wird - z.B. weil in den Daten ein Fehler drin ist. Er korrigiert den Fehler, will wieder speichern und es geht wieder nicht, weil die Datei noch vom letzten Mal geöffnet ist - der Filestream wurde ja nicht freigegeben!

Ein Speicherleck ist zwar nicht schön aber RAM ist meistens genug da. Wenn andere Ressourcen nicht freigegeben werden, kann es schon ärgerlicher werden. Und genau dafür hat man ja try-finally

[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.

[Aphton]

Zitat von stahli:

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

Ähm, dann werden die folgenden Befehle nicht mehr ausgeführt, da der finally Block unbedingt ausgeführt wird und ein Exit dort veranlasst das Verlassen der Funktion. Dh. es kommt nie zu einem:
DoNotIfExitBefore

[Stevie]

Mag nur meine Meinung, aber für jedes Exit sollte es einen Schlag in den Nacken geben.
Klar, an manchen Stellen kann man sich in etwas vertrackten Konstrukten einfach aus der Affaire ziehen, aber sauber gecoded ist es zu 99.99% vermeidbar.

[omata]

@Stevie: Danke, genau diese Worte habe ich mir beim Lesen dieses Themas gewünscht

[Aphton]

Zitat von Stevie:

Mag nur meine Meinung, aber für jedes Exit sollte es einen Schlag in den Nacken geben.
Klar, an manchen Stellen kann man sich in etwas vertrackten Konstrukten einfach aus der Affaire ziehen, aber sauber gecoded ist es zu 99.99% vermeidbar.

Ähm, ja, ich hab das auch die meiste Zeit gedacht, aber um den Code kürzer zu halten, ist es wirklich sinnvoll, hier und da mal Exit zu verwenden.
Ein Beispiel:

Delphi-Quellcode:

// mit Exit
begin
  if not FileExists(Filename) then Exit;
  LoadFile();
  ProcessFile();
  DoSomethingElseWithFile();
end;

// ohne Exit
begin
  if FileExists(Filename) then
  begin // extra Zeile
// + Verschachtelung
    LoadFile();
    ProcessFile();
    DoSomethingElseWithFile();    
  end; // extra Zeile

[stahli]

Zitat von Aphton:

Zitat von Stevie:

Mag nur meine Meinung, aber für jedes Exit sollte es einen Schlag in den Nacken geben.
Klar, an manchen Stellen kann man sich in etwas vertrackten Konstrukten einfach aus der Affaire ziehen, aber sauber gecoded ist es zu 99.99% vermeidbar.

Ähm, ja, ich hab das auch die meiste Zeit gedacht, aber um den Code kürzer zu halten, ist es wirklich sinnvoll, hier und da mal Exit zu verwenden.
Ein Beispiel:

Delphi-Quellcode:

// mit Exit
begin
  if not FileExists(Filename) then Exit;
  LoadFile();
  ProcessFile();
  DoSomethingElseWithFile();
end;

// ohne Exit
begin
  if FileExists(Filename) then
  begin // extra Zeile
// + Verschachtelung
    LoadFile();
    ProcessFile();
    DoSomethingElseWithFile();    
  end; // extra Zeile

Sehe ich auch so. Der Code wird u.U. einfach kürzer und übersichtlicher.
Zumal man mit Exit(Value) in Funktionen auch gleich einen Result-Wert zuweisen kann.