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.