![]() |
Re: Möglichkeit: Try ... Except ... Finally ?
Hi Bbommel,
bei solchen Konstrukten würde der Code nicht mehr gehen
Delphi-Quellcode:
begin
SomeOne := TSomeone.Create; try try doSomething; ... ... except Bam; Exit; end; finally SomeOne.Free; end; UndhierNochwasmachenwennnichtbeendetwurde; UndNochwas; ... end; |
Re: Möglichkeit: Try ... Except ... Finally ?
ich glaub ganz richtig wäre es so:
Delphi-Quellcode:
Dann sollte das hinter finally nur ausgeführt werden wenn keine exception geworfen wurde.
try
try [...] except raise; end; finally [...] end; [...] |
Re: Möglichkeit: Try ... Except ... Finally ?
Ah, okay... das finally wird also dann auch trotz des "exit" noch ausgeführt? Okay, wieder was gelernt... bisher wollte ich zum Glück das Gegenteil (also, dass er eben sehr wohl weitermacht), sonst müsste ich mich jetzt Ärgern, dass ich ein Feature nicht kannte. Danke für die Erklärung.
Bis denn Bommel |
Re: Möglichkeit: Try ... Except ... Finally ?
Dein "puh" wird nicht nur nicht ausgeführt, wenn du eine neue Exception wirfst; es genügt, wenn du auf spezielle Exceptions reagierst (on E: EWhatever do). Dann werden andere Exceptions nämlich durchgereicht und dein "puh" kommt nicht zum Zuge.
|
Re: Möglichkeit: Try ... Except ... Finally ?
Hi,
Zitat:
Delphi-Quellcode:
Der Benutzer fragt sich nun, warum das keine Zahl war.
try
StringList.Add(StrToInt(Edit.Text)); //Bei Add --> z. B. EOutOfResources except ShowMessage('Bitte Zahl eingeben!'); end;
Delphi-Quellcode:
Hier werden trotz Abort foo und bar aufgerufen - und eventuell noch ganz andere Vorgänge ausgeführt, die eigentlich Abgebrochen werden sollten.
try
Abort; except foo; end; bar; Etwas anderes ist es, wenn man raise; dazu schreibt.
Delphi-Quellcode:
Mfg
function CreateBitmapFromFile(const FileName: String): TBitmap;
begin Result := TBitmap.Create; try Result.LoadFromFile(FileName); except Result.Free; raise; end; end; FAlter |
Re: Möglichkeit: Try ... Except ... Finally ?
Dieser Thread erinnert mich gerade an ein Problem, welches ich einmal mit Except+Finally hatte.
Ich habe mich entschlossen, den except-block innerhalb des finally-blocks zu machen: try-try-except-finally-end. In diesem Falle würde die Aufräumprozedur (vorzugsweise mit einem if Assign() vor dem .Free) immer noch stattfinden. Doch was wäre, wenn im Finally auch noch eine Exception ausgelöst wird? Und ich frage mich, ob es überhaupt (in irgend einer Situation) Sinn macht, die Reihenfolge mal zu verdrehen: try-try-finally-except-end . Oder ist das vielleicht sogar egal? Gruß blackdrake |
Re: Möglichkeit: Try ... Except ... Finally ?
Ein Except-Block wird nur im Fehlerfall angesprungen, ein Finally-Block immer. Das heißt in logischer Konsequenz, dass Fehlerbehandlungsroutinen in einen Except-Block gehören, Aufräumarbeiten hingegen in einen Finally-Block.
Delphi-Quellcode:
So könnte das aussehen.
Bla := TBla.Create;
try try Bla.Machwas; except on EWuppdi do MessageBox(0,'Es ist ein Wuppdi aufgetreten.','Fehler',MB_OK or MB_ICONERROR); end; finally Bla.Free; end; |
Re: Möglichkeit: Try ... Except ... Finally ?
Zitat:
ein Wuppdi ist doch kein Fehler! Eine so hohes Wuppdi-Level wie in der DP ist eine Ausnahme (Exception), aber nicht jede Ausnahme muss ein Fehler sein. Ein hohes Wuppdi-Level ist im Gegenteil richtig toll! :dp: Mfg FAlter :mrgreen: |
Re: Möglichkeit: Try ... Except ... Finally ?
Zitat:
Ich frage mich aber, ob es überhaupt irgendeinen Sinn hat, das ganze so zu schreiben (andersherum zu verschachteln):
Delphi-Quellcode:
Wäre das dann ein grober Fehler oder allgemein Problematisch?
try
Bla := TBla.Create; try Bla.MachWas(); finally Bla.free; end; except showmessage('Blubb'); end; Gruß blackdrake |
Re: Möglichkeit: Try ... Except ... Finally ?
Je nach Anwendungsfall kann diese Reihenfolge doch durchaus logisch sein.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 07:23 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