![]() |
finally - Code aufrufen
Hi,
folgender Code:
Delphi-Quellcode:
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?
try
ausgabe := 0; if eingabe = 0 then raise Exception.Create('Eingabe darf nicht 0 sein'); ausgabe := zahl + eingabe; finally ShowMessage(IntToStr(ausgabe)); end; 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:
Springt es dann auch noch in den finally Teil bevor es die Methode verlässt?
if eingabe = 0 then
begin raise Exception.Create('Eingabe darf nicht 0 sein'); Exit; end; Thx :-) |
Re: finally - Code aufrufen
Es hupft sofort in den nächsten Finally-Block, oder in den nächsten Except-Block.
|
Re: finally - Code aufrufen
Sowohl bei Exit als auch bei ner manuellen Exception?
|
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. |
Re: finally - Code aufrufen
Ok, danke dir für die schnelle und kompetente Hilfe :-) :dp:
|
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!
|
Re: finally - Code aufrufen
Zitat:
|
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. |
Re: finally - Code aufrufen
Zitat:
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