Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi finally - Code aufrufen (https://www.delphipraxis.net/106539-finally-code-aufrufen.html)

Flips 12. Jan 2008 14:42


finally - Code aufrufen
 
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 12. Jan 2008 14:44

Re: finally - Code aufrufen
 
Es hupft sofort in den nächsten Finally-Block, oder in den nächsten Except-Block.

Flips 12. Jan 2008 14:47

Re: finally - Code aufrufen
 
Sowohl bei Exit als auch bei ner manuellen Exception?

sirius 12. Jan 2008 14:49

Re: finally - Code aufrufen
 
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 12. Jan 2008 15:02

Re: finally - Code aufrufen
 
Ok, danke dir für die schnelle und kompetente Hilfe :-) :dp:

grenzgaenger 12. Jan 2008 15:28

Re: finally - Code aufrufen
 
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 12. Jan 2008 16:21

Re: finally - Code aufrufen
 
Zitat:

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 :zwinker:

grenzgaenger 12. Jan 2008 16:25

Re: finally - Code aufrufen
 
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 12. Jan 2008 16:27

Re: finally - Code aufrufen
 
Zitat:

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?


Alle Zeitangaben in WEZ +1. Es ist jetzt 01:06 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz