"FinalllyExit" gewünscht

[stahli]

@Omata
Sofern nur ein Try-Block existiert stimmt das (habe ich ja in meinem Projekt jetzt auch so genutzt).
Aber die Struktur ist unschön, sofern in FuncA ein Fehler auftritt. Dieser ist schwerer zu finden, als wenn es keinen Try-Block gäbe.

Delphi-Quellcode:

begin
  try
    FuncA;
    FuncB;
    // hier kommt alles rein
  finally
    // Bei Fehler in FuncA geht es kommentarlos hier weiter.
    // und das hier wird vor dem Verlassen ausgeführt, egal, was vorher war.
  end;
end;

@NamenLozer
Naja, man könnte sich die Verschachtelungen sparen.
Und ein Try-Block ist ja nicht dafür da, einen Funktionsaussprung zu regeln, sondern Fehler abzufangen.
Das ist aber nicht mein Anliegen.

Man könnte sich ja auch eine abschließende Ergebnisberechnung vorstellen, z.B.

Delphi-Quellcode:

Result := A+B+C

, die an 10 verschiedenen Stellen notwendig werden kann.
Mit FinallyExit bräuchte man dies nur als letzte Zeile deklarieren und könnte überall einfach Exit aufrufen, das den Resultwert berechnet und den Rücksprung veranlasst.
Ich fände das übersichtlich und logisch.


@all
Aber ok, ich gebe mich geschlagen. :?

[omata]

Zitat:

Zitat von stahli (Beitrag 1101891)

Aber die Struktur ist unschön, sofern in FuncA ein Fehler auftritt. Dieser ist schwerer zu finden, als wenn es keinen Try-Block gäbe.

Das verstehe ich nicht. Delphi hat so einen guten Debugger, da kann doch Zeile für Zeile sehr gut überprüft werden. Vor jedem Debug-Step muss man selbst überlegen, was als nächstes passiert. Da ist nichts unübersichtlich. Sorry, ich verstehe es nicht.

[stahli]

Ohne den Try-Block in der übergeordneten Methode hätte es SOFORT eine schöne Fehlermeldung in der Funktion gegeben.
Durch den Try-Block wurde die unterdrückt. Ich habe den Fehler ja letztlich gefunden aber ich bin immer noch der Meinung, dass try nur bei "ERWARTETEN FEHLERN" Sinn macht (z.B. E/A-Fehler), auf die dann reagiert werden muss.

Was nutzt es mir, wenn 2 Objekte freigegeben werden, aber der eigentliche Methodenzweck fehl geschlagen ist.
Except macht ja u.U. Sinn, aber finally (ohne Fehlerbehandlung)?

Aber ich wiederhole mich. Soll also genug sein.

[omata]

Mir fehlen da einfach die Worte, wenn ich das lese. Aber für dich gibt es doch eine ganz einfache Lösung: Verwende Try-Finally einfach nicht, dann ist deine Welt doch in Ordnung. Für den Rest gibt es halt dieses Konstrukt und diese Personen können das dann verwenden. Dann sind doch alle glücklich.

[himitsu]

Finally unterdrückt keine Exceptions,
denn am Ende des Finally-Blocks wir die Exception automatisch wieder ausgelöst.
(es sei denn es tritt in Finally eine Anderere/Neue Exception auf, dann wird diese weitergereicht)

Zitat:

Delphi-Quellcode:

procedure xyz;
begin
  A := TA.Create;
  B := TB.Create;
  try
    ...
  finally
    A.Free;
    B.Free;
  end;
end;

Ist unsicher, wie richtig gesagt wurde, denn A wird nicht freigegeben, wenn es in TB.Create knallt.

Delphi-Quellcode:

procedure xyz;
begin
  A := TA.Create;
  B := TB.Create;
  ...
  FinallyExit:
  A.Free;
  B.Free;
end;

Ist nicht viel besser, denn A und B wurden nicht initialisiert und wenn es in einem der Konstruktoren knallt. dann nallt es auch bei den uninitialisierten Free's.
Außerdem übersieht man das FinallyExit schnell mal ... so erkennt man nicht, daß es da einen Schutzblock gibt und man sieht nicht wo der Block aufhört.

Delphi-Quellcode:

procedure xyz;
begin
  A := TA.Create;
  try
    B := TB.Create;
    try
      ...
    finally
      B.Free;
    end;
  finally
    A.Free;
  end;
end;

// oder 
procedure xyz;
begin
  A := nil;
  B := nil;
  try
    A := TA.Create;
    B := TB.Create;
    ...
  finally
    A.Free;
    B.Free;
  end;
end;

// oder 

procedure xyz;
begin
  B := nil;
  A := TA.Create;
  try
    B := TB.reate;
    ...
  finally
    A.Free;
    B.Free;
  end;
end;

so sieht es schon besser aus

[Namenloser]

Zitat:

Zitat von stahli (Beitrag 1101891)

Und ein Try-Block ist ja nicht dafür da, einen Funktionsaussprung zu regeln, sondern Fehler abzufangen.

Sagt wer? Try-Except ist zum Abfangen von Fehlern, ja, Try-Finally nicht unbedingt. Man verwendet Try-Finally zwar oft dazu, Ressourcen garantiert (auch im Falle eines Fehlers) wieder freizugeben, aber wie man sieht gibt es nicht nur diesen Anwendungsfall. Im Grunde heißt Try-Finally nur, dass ein bestimmter Code versuchsweise ausgeführt werden soll, und anschließend garantiert ein bestimmter anderer Code.

[stahli]

Zitat:

Zitat von himitsu (Beitrag 1101896)

Delphi-Quellcode:

procedure xyz;
begin
  A := TA.Create;
  B := TB.Create;
  ...
  FinallyExit:
  A.Free;
  B.Free;
end;

Es käme mir dabei eben nicht darauf an, wenn es "knallt". Gegeben sei eine tadellos funktionierende Funktion.
Deine 3 Punkte bearbeiten jede Menge Fallunterscheidungen, komplexe Verschachtelungen, Funktionsaufrufe usw.
An unterschiedlichen Stellen kann Exit aufgerufen werden und final noch etwas erledigt werden.
Das Ganze hat NICHTS mit Versuchen oder Fehlern zu tun. Es gibt diverse Abläufe und diverse Aussprünge.

Wie Eingangs schon diskutiert, kann man mit jeder Menge if..begin...end..else.. und temporären Flags arbeiten, ggf. auch mit Goto (wenn es nicht gleich wieder Aufschreie gibt).
Das sehr komfortable Exit(Value) lässt sich aber damit nicht nutzen.

Aber ok, wir kommen nicht zusammen. Dann lassen wir es einfach. Es war aber eine Weltidee. :-D

[Namenloser]

@stahli: Aber genau was du beschreibst, das macht doch try-finally. Verabschiede dich doch mal von dem Gedanken, dass try-finally immer was mit Fehlern zu tun hat.

Delphi-Quellcode:

procedure xyz;
begin
  A := TA.Create;
  B := TB.Create;
  ...
  FinallyExit:
  A.Free;
  B.Free;
end;

ist 100% äquivalent zu

Delphi-Quellcode:

procedure xyz;
begin
  try
    A := TA.Create;
    B := TB.Create;
    ...
  finally
    A.Free;
    B.Free;
  end;
end;

(auch wenn das so, wie bereits gesagt, wenig sinnvoll ist)

[omata]

Zitat:

Zitat von stahli (Beitrag 1101899)

Es war aber eine Weltidee. :-D

Ja, à la Dittsche :hi:

[FredlFesl]

Ein Konstruktor sollte doch niemals eine Exception werfen. Und wenn, braucht man das Objekt nicht freizugeben, weil die Konstruktorlogik den Speicher selbst wieder freigibt, bevor sie die Exception erneut schmeisst.

Try...Finally ergibt auch nur dann Sinn, wenn die Exception in einem der Aufrufer abgefangen und behandelt wird. Wenn ich beispielsweise irgendeine Verbindung 'öffne' und dann etwas mit ihr anstelle, möchte ich, das die Verbindung garantiert wieder geschlossen wird, bevor eine Stufe höher die Exception behandelt wird.

In C# gibt es übrigens etwas Ähnliches, nämlich das 'Using' - Konstrukt.

Zitat:

Zitat von NamenLozer (Beitrag 1101897)

Im Grunde heißt Try-Finally nur, dass ein bestimmter Code versuchsweise ausgeführt werden soll, und anschließend garantiert ein bestimmter anderer Code

Stimmt nicht ganz (also, das 'versuchsweise'). Dann würde 'Exit' nicht in den 'Finally'-Block springen. das 'garantiert' ist das Wesentliche.

Zitat:

Zitat von stahli (Beitrag 1101899)

Es käme mir dabei eben nicht darauf an, wenn es "knallt".

...Ahh. Geht mit 'try...finally'

Zitat:

Zitat von stahli (Beitrag 1101899)

An unterschiedlichen Stellen kann Exit aufgerufen werden und final noch etwas erledigt werden.

...Ahh. Geht mit 'try...finally'

Zitat:

Zitat von stahli (Beitrag 1101899)

Wie Eingangs schon diskutiert, kann man mit jeder Menge if..begin...end..else.. und temporären Flags arbeiten, ggf. auch mit Goto (wenn es nicht gleich wieder Aufschreie gibt).

Uaaaaarghl! (zufrieden? ;-) ) Deshalb wurde doch gerade try..finally erfunden

Zitat:

Zitat von stahli (Beitrag 1101899)

Das sehr komfortable Exit(Value) lässt sich aber damit nicht nutzen.

Weswegen man eben mit try..finally arbeitet.


Dein 'FinallyExit' widerspricht dem Gedanken der blockorientierten Programmiersprache und schränkt den Programmierer unnötig ein.
Beispiel:
...

Delphi-Quellcode:

FuncA();
Try
  FuncB();
Finally
  CleanupFuncBCallAndDefinetlyNotTheFuncACall();
End;

Wie willst Du das mit deinem 'FinallyExit' modellieren? Beachte, das FuncA außerhalb des Try..Finally steht und dieser Aufruf nicht aufgeräumt werden soll, wenn er schiefgeht.