Möglichkeit: Try ... Except ... Finally ?

[LuCSteR]

Hey,

hab ne Syntaxfrage.
Wie ist es zu formulieren?

Delphi-Quellcode:

try
  begin
    bla;
    blubb;
  end;
except
  begin
    bam;
  end;
finally puh;

Ist sowas möglich? Hab es gerade ausprobiert, aber Compiler meckert, Illegal Expressen beim finally.
Es geht speziell um eine Ini File. Im Try-Block versucht er zu lesen/zu schreiben. Except-Block soll eine Fehlermedlung gezeigt werden, wenn das nicht klappen sollte und Ini.free. Im finally muss ich Ini.free setzen, weil sonst danach garnichts mehr ausgeführt wird. Das ganze findet in einer FormCreate Prozedur statt.

Grüße.

[mkinzler]

Entwder

Delphi-Quellcode:

except

oder

Delphi-Quellcode:

finally

[LuCSteR]

Also funktioniert das nicht auf meinem Wege? Mmh. Was bringt mir dann die Try-Except, Try-Finally Option?
Bei Java funktioniert das doch auch.
Habe auch versucht Ini.free am Ende des Try-Blocks zu setzen. Bekomme ich allerdings das gleiche Ergebnis, wie wenn ich es außerhalb des Try-Except platziere. Es funktioniert nur, wenn das Ini.Free im Finally-Block sitzt :(

[mkinzler]

finally wird immer aufgerufen.

Delphi-Quellcode:

try
  try
    ...
  except
    ..
  end;
finally
  ..
end;

[Bernhard Geyer]

Leider hat Delphi hier kein so schönes Konstrukt das man try..except..finally ein einem Block verwenden kann :-(

[bernau]

Zitat:

Zitat von LuCSteR

Hey,

Delphi-Quellcode:

try
  begin
    bla;
    blubb;
  end;
except
  begin
    bam;
  end;
finally puh;

Entweder except oder finally.

Du kannst es so schreiben:

Delphi-Quellcode:

try
  bla;
  blubb;
  puh; // Hier wird es nur ausgeführt, wenn die zwei befehle vorher korrekt abgearbeitet wurden.
except
   bam; //Das wir ausgeführt, wenn ein Fehler auftritt.
end;

[/quote]

[mkinzler]

Was genau das gegengesetzte wäre, was er will

[Angel4585]

Zitat:

Zitat von mkinzler

finally wird immer aufgerufen.

Delphi-Quellcode:

try
  try
    bla;
    blubb;
  except
    bam;
  end;
finally
  puh;
end;

[DeddyH]

Man muss das wohl schon so machen, wie in #4 beschrieben.
Pseudo-Code:

Delphi-Quellcode:

Ini := TIniFile.Create(Pfad);
try
  try
    Ini.ReadSomething
  except
    on e: Exception do
      ShowMessage(e.Message);
  end;
finally
  Ini.Free;
end;

[LuCSteR]

Alles klar, da hätte ich auch selbst drauf kommen können :)
Außerdem hatte ich auch nen "begin - end" zu viel drinne :s

Vielen Dank für die Hilfe.


----

Hab grad noch schnell Bernaus's Vorschlag probiert.
Funktioniert in meinem Fall genauso hervorragend, wie mkinzler's Lösung. Allerdings ist mkinzler's Lösung sicherer :)
Danke euch beiden. :)

Btw. hatte es schon wie Bernau probiert, jedoch, wie oben schon geschreiben, ein begin - end an der falschen Stelle. :s

[mkinzler]

Dann wäre aber der finally-Abschnitt der falsche Ort gewesen

[DeddyH]

Wofür?

[LuCSteR]

Es musste nur igrendwo im Zusammenhang mit dem Try das Ini.Free gesetzt werden. Funktioniert am ende von try, genauso wie im finally block. Blos wenn vorher im try block irgendwas nicht funktioniert, arbeitet er das ini.free nicht mehr ab. So wie es Bernau schon kommentiert hat. Deswegen auch besser im finally block aufgehoben.

[mkinzler]

Zitat:

Zitat von DeddyH

Wofür?

Wenn etwas in finally steht, wird es immer ausgeführt, wenn im Try-Block nur wenn vorher kein Fehler aufgetreten ist.

[Bbommel]

Hm, über die Diskussion try...except...finally stolpert man ja hier beim Mitlesen öfter mal. Meistens wundere ich mich, was eigentlich gegen ein einfaches (um es mal auf das urpsrüngliche Beispiel zu beziehen)...

Delphi-Quellcode:

try
  bla;
  blubb;
except
  bam;
end; 

puh;

...spricht. Hier würde man kein finally benötigen, weil das puh schon allein durch den try-except-Block auch bei einem Fehler immer ausgeführt wird.

Oder ist an diesem Ansatz irgendwas falsch/unschön?

Bis denn
Bommel

edit: 'n paar begin...end entfern...

[LuCSteR]

So hatte ich es urprünglich geschrieben. Das Ini.Free quasie nach der Abhandlung Try-Except auszuführen. Nur musste ich dann mit Erschüttern festellen, das alle Folgenden Funktionen/Befehle nichts mehr gemacht haben. So z.b. (findet ja alles in einer OnFormCreate statt) sollte ein Ordner erstellt werden, was dann allerdings nicht mehr funktionierte. nach ein paar Untersuchungen stellte ich dann fest, das das Ini.Free das Problem war. Das muss wie schont erwähnt mit in das Try bzw sicherer ins finally.

Jetzt funktioniert ja alles wieder prächtig :)

[xaromz]

Hallo,

Zitat:

Zitat von Bbommel

Delphi-Quellcode:

try
  bla;
  blubb;
except
  bam;
end; 

puh;

Das funktioniert nur solange, bis Du im Except-Teil eine neue Exception wirfst.

Gruß
xaromz

[bernau]

Zitat:

Zitat von mkinzler

Was genau das gegengesetzte wäre, was er will

Sorry. Hast recht. Wenn man nebenbei was macht........

Das folgende Beispiel ist richtig. Ein umschliessendes finally ist eigendlich nicht nötig. Ausser es tritt im Except noch eine exception auf.

Delphi-Quellcode:

try 
  bla; 
  blubb; 
except 
  bam; //Das wir ausgeführt, wenn ein Fehler auftritt. 
end;
puh; // Das wird auf jedenfall abgearbeitet. Egal was oben passiert.

[Bbommel]

Hm, merkwürdig. Ich setze die Konstruktion, wie ich sie beschrieben habe, an einigen Stellen in meinen Programmen ein und eigentlich klappt das immer wunderbar:

Delphi-Quellcode:

try
  irgendwas;
except
  fehlermedlung_oder_so;
end;

aufraeumen;
weitere_befehle;

Alle Zeilen nach dem try-except-Block werden bei mir immer ausgeführt - sonst hätte ich hier in manchen Programmen richtige Probleme. try-finally nutze ich eigentlich so gut wie gar nicht, weil ich immer dachte, der würde dann eben nur noch den finally-Teil ausführen und dann nix mehr. Also:

Delphi-Quellcode:

try
  irgendwas;
finally
  aufraeumen;
end;

weitere_befehle;

Im zweiten Beispiel würde zwar auch aufgeräumt, aber keine weiteren Befehle mehr ausgeführt. Dachte ich.

Jetzt bin ich verwirrt. Aber glücklich. Läuft ja bei uns beiden. ;)

(Bin aber dennoch für Aufklärung dankbar)

@xaromz: Naja, okay, normalerweise gebe ich da nur Fehlermeldungen aus oder setze Variablen auf default-Werte, da sollte dann nix mehr passieren. Dass man da sonst auch wieder Fehlerbehandlungen machen muss, ist klar, aber die Frage bliebe ja die gleiche: auch das könnte ich ja prinzipiell durch mehrere verschachtelte try-except-Blöcke machen...
Bis denn
Bommel

[DeddyH]

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var sl: TStringlist;
begin
  try
    sl.Add('Bumm');
  except
    ShowMessage('Oha');
    exit;
  end;
  ShowMessage('Huhu');
end;

Da kommt kein "Huhu".

[angos]

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;

[SirThornberry]

ich glaub ganz richtig wäre es so:

Delphi-Quellcode:

try
  try
    [...]
  except
    raise;
  end;
finally
  [...]
end;
[...]

Dann sollte das hinter finally nur ausgeführt werden wenn keine exception geworfen wurde.

[Bbommel]

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

[Apollonius]

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.

[FAlter]

Hi,

Zitat:

Zitat von Apollonius

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.

Und genau das sollte man immer machen. Sonst verliert beispielsweise Abort die Wirkung, oder man merkt gar nicht, dass man eine ganz andere Meldung anzeigt als zu der aufgetretenen Exception passt.

Delphi-Quellcode:

try
  StringList.Add(StrToInt(Edit.Text)); //Bei Add --> z. B. EOutOfResources
except
  ShowMessage('Bitte Zahl eingeben!');
end;

Der Benutzer fragt sich nun, warum das keine Zahl war.

Delphi-Quellcode:

try
  Abort;
except
  foo;
end;
bar;

Hier werden trotz Abort foo und bar aufgerufen - und eventuell noch ganz andere Vorgänge ausgeführt, die eigentlich Abgebrochen werden sollten.

Etwas anderes ist es, wenn man raise; dazu schreibt.

Delphi-Quellcode:

function CreateBitmapFromFile(const FileName: String): TBitmap;
begin
  Result := TBitmap.Create;
  try
    Result.LoadFromFile(FileName);
  except
    Result.Free;
    raise;
  end;
end;

Mfg
FAlter

[blackdrake]

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

[DeddyH]

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:

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;

So könnte das aussehen.

[FAlter]

Zitat:

Zitat von DeddyH

on EWuppdi do
MessageBox(0,'Es ist ein Wuppdi aufgetreten.','Fehler',MB_OK or MB_ICONERROR);
[/delphi]

Hi,

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:

[blackdrake]

Zitat:

Zitat von DeddyH

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.

Ja, ist mir bekannt.

Ich frage mich aber, ob es überhaupt irgendeinen Sinn hat, das ganze so zu schreiben (andersherum zu verschachteln):

Delphi-Quellcode:

try
  Bla := TBla.Create; 
  try
    Bla.MachWas();
  finally
    Bla.free;
  end;
except
  showmessage('Blubb');
end;

Wäre das dann ein grober Fehler oder allgemein Problematisch?

Gruß
blackdrake

[DeddyH]

Je nach Anwendungsfall kann diese Reihenfolge doch durchaus logisch sein.