finally - Code aufrufen

[Flips]

Hi,

folgender Code:

Delphi-Quellcode:

try 
  ausgabe := 0;
  if eingabe = 0 then
    raise Exception.Create('Eingabe darf nicht 0 sein');
  ausgabe := zahl + eingabe;
finally
  ShowMessage(IntToStr(ausgabe));    
end;

So, nehmen wir an ich gebe jetzt 0 ein, dadurch wird die Exception ausgelöst. Springt Delphi nach der Exception direkt in den finally Teil oder führt es den Code weiter aus?
Wenn es den Code weiter ausführt, gelingt mir ein Sprung dann nur mit einem except-Teil?


Natürlich könnte ich auch einfach schreiben:

Delphi-Quellcode:

if eingabe = 0 then
  begin
    raise Exception.Create('Eingabe darf nicht 0 sein');
    Exit;
  end;

Springt es dann auch noch in den finally Teil bevor es die Methode verlässt?

Thx

[sirius]

Es hupft sofort in den nächsten Finally-Block, oder in den nächsten Except-Block.

[Flips]

Sowohl bei Exit als auch bei ner manuellen Exception?

[sirius]

Also, das exit nach dem raise Exception brauchst du nicht, da kommt das Programm nie hin.

Unabhängig davon springt aber ein Exit auch in den Finally-Block. In einen Finally-Block setzt man i.A. Variablen zurück und gibt Speicher frei.

[Flips]

Ok, danke dir für die schnelle und kompetente Hilfe

[grenzgaenger]

mal davon abgesehen, solltest du solche konstrukte vermeiden. raise und exception nur wenn es gar nicht anders geht. ist eigentlich ein systemübergreifender goto nur noch schlimmer!

[sirius]

Zitat von grenzgaenger:

mal davon abgesehen, solltest du solche konstrukte vermeiden. raise und exception nur wenn es gar nicht anders geht. ist eigentlich ein systemübergreifender goto nur noch schlimmer!

Warum denn. Ist klar, dass es in dem Beispiel nicht sinvoll ist. Aber ich denke, de rOP hat sein eigentliches Problem hier nur vereinfacht dargestellt. Und try..Finally setzt dein Compiler in jeder Funktion, in der du dynamische Variablen verwendest

[grenzgaenger]

try
finally
end

ist ja ok. da ist ja nix gegen zu sagen, im gegenteil . meine kritik ging an die exeptions mit raise... das ist es was man vermeiden sollte und nur in wirklichen notfällen, wenn es keine andere möglichkeit gibt, einsetzen sollte.

wünsch dir noch einen schönen abend.

[r2c2]

Zitat von grenzgaenger:

mal davon abgesehen, solltest du solche konstrukte vermeiden. raise und exception nur wenn es gar nicht anders geht. ist eigentlich ein systemübergreifender goto nur noch schlimmer!

Da bin ich anderer Meinung. Exceptions sind gerade dazu da, damit man sich nicht drum kümmern muss, was jetzt alles nicht mehr ausgeführt werden darf. Und das was ausgeführt werden muss, steht eh im finally. Genau das ist doch der Sinn von exceptions: Sich auf einfache Weise aus einer Ausnahmesituation ui retten. Damit braucht man die ganzen fehleranfälligen, unpraktischen und schlecht erweiterbaren Fehlercodes nicht mehr, etc.

Mal n paar Hinweise an denen man IMHO überprügfen kann, ob man Exceptions richtig einsetzt:
- Exceptions nur in inneren Klassen; nicht in Formularklassen
- solche spätetens in dn Formularklassen wieder fangen (in manchen - eher seltenen - Fällen macht es auch Sinn dies früher zu tun)
- trotzdem immer versuchen, dass die Ausnahmesituation gar nicht erst auftritt(Beispiel: mit FileExists prüfen, statt den fehler im except abfangen)
- in den finally-Block nur zum freigeben: Free, FreeMem, FreeAndnil
- in den except-Block nix, was wieder ne Exeption auslösen könnte
- ggf. nach Fehlerklassen unterscheiden ==> on
- für ne eigene Klassen auch eigene Fehlerklassen schreiben. nicht exception direkt benutzen
- wenn es schon eine passende Fehlerklasse gibt, nicht noch eine schreiben
- der Exception alle benötoigen Infos mitgeben
- ...

mfg

Christian

P.S.: Zum eigentlichen Problem: Gibt es irgend einen Grund, warum du es nicht einfach ausprobierst bzw. ausporobiert hast?