Geht auch try...finally....except?

[gerrit.lober]

Hallo,

ich habe einen try...except...-Block und möchte nun noch finally einfügen,
funktioniert das?

[sakura]

Nicht direkt, aber schachteln geht immer:

Delphi-Quellcode:

try
  try
  finally
  end;
except
end;

...:cat:...

[Tyrael Y.]

jein!! :mrgreen:

zb

Delphi-Quellcode:

try
  myObj := TMyObj.create;
  try
    ....
  finally
    myObj.free;
  end; 
except
  HandleException;
end;

[Phoenix]

Erm. Soltte das nicht andersrum geschachtelt werden?

Also sorum:

Delphi-Quellcode:

try
   try
      // tu was
   except
     // behandle Fehler
   end;
finally
   // aufräumen
end;

Weil andersrum würde er in den Except ja gar nicht mehr reinlaufen, wenn der nicht weitergeraised würde.

[Waldteufel]

Hi.

Moment... Wenn die Exception nicht weitergeraised wird, ist

Delphi-Quellcode:

try
  {...1}
  try
  except
  end;
finally
  {...2}
end;

dann nicht das selbe wie

Delphi-Quellcode:

{...1}
try
except
end;
{...2}

:?: (Mal abgesehen, dass try...finally und try...except die Programmausführung verlangsamen und die 2. methode somit schneller ist...)

[glkgereon]

nein

wenn in 1 ein fehler kommt wird 2 nicht mehr ausgeführt (bei der 2ten methode)

EDIT:
dasselbe wäre das:

Delphi-Quellcode:

try
{...1} 
except
end;
{...2}

[alcaeus]

Zitat:

Zitat von Waldteufel

:?: (Mal abgesehen, dass try...finally und try...except die Programmausführung verlangsamen und die 2. methode somit schneller ist...)

Egal ob es langsamer ist oder nicht, das bemerkt der Endbenutzer in 99% der Faelle sowieso nicht. Mit try-finally verhinderst du auf alle Faelle Speicherlecks etc.

Greetz
alcaeus

[Tyrael Y.]

selbstverständlich würde das except die Exception kriegen, ...gehen würd auch

Delphi-Quellcode:

try
 myObject := TMyObject.Create; 
 try
  try
    myObject.FirstProcedure();
  except
    MachWas;
    raise;
  end;
  ...
  try
    myObject.OtherProcedure();
  except
    MachWas; 
  end;
 finally
  myObject.Free;
 end;  
except
  HandleException;
end;

..bei dem Beispiel würde bei einer Exception bei FirstProcedure diese behandelt
und weitergegeben ducrh das raise;
..bei einer Exception bei OtherProcedure würde dieser in dem ihn umgebenden except
behandelt aber zum äusseren except nicht weitergegeben..

es kommt immer auf deine Bedürnisse an, aber die Verschachtelung geht immer


mfg

[Speedmaster]

Wie ist das eigenltich verlangsamt sich das Programm auch( sehr ) wenn ich eine Programmumfassende try..except..end Anweisung Einfüge?

[Tyrael Y.]

Programmumfassend? Wie meinst du das? :gruebel:

[Speedmaster]

So:

Delphi-Quellcode:

program Programmumfasend;

begin
  try

  except

  end;
end.

[Binärbaum]

Zitat:

Zitat von Speedmaster

Wie ist das eigenltich verlangsamt sich das Programm auch( sehr ) wenn ich eine Programmumfassende try..except..end Anweisung Einfüge?

IMHO würde das kaum einen großen Unterschied machen, ob man nur einige Zeilen oder fast den gesamten Code mit try...except/finally umgibt. Allerdings wenn es mehrere Blöcke sind....

Dennoch würde ich nur dazu raten, solchen Code in try..except/finally zu kapseln, wo auch wirklich eine Exeption abgefangen werden muss.

MfG
Binärbaum

[Speedmaster]

Naja ich weiss nicht ob das nicht Sinnvoll wäre es doch so zu machen, da ja bald( 2006 ) der Cell Processor rauskommt wird die Geschwindigkeit weniger ein Problem sein, allerdings hat man dann ein Programm was Praktisch "ohne Fehler" läuft( B.z.w. sie werden alle abgefangen ).

[Tyrael Y.]

Zitat:

Zitat von Speedmaster

So:

Delphi-Quellcode:

program Programmumfasend;

begin
  try

  except

  end;
end.

Das Problem dabei wäre auch, daß du deine Exceptions nicht vernünftig behandlen kannst, da du nicht weisst woher sie kommen und wenn du auch wüsstest woher sie kommen, dann sind diese Objekte z.B. in dieser Unit nicht bekannt...

Den Except-Block immer um eine mögliche Fehlerquelle setzen und dort auch behandeln, dann liegts du immer richtig und wenn es nötig ist, die Exception raisen und beim nächsten darüber leigenden Except-Block behandeln...


mfg

Edit:

PS: Zur Geschwindigkeit

Die Geschwindigkeit wird nciht großartig beeinträchtigt, solange du nicht im Except-Block zeitaufwendige sachen machst

mit Except-Block meine ich diese Stelle..

Delphi-Quellcode:

try
...
except
  <--- Hier
end;

[freak4fun]

Wenn du dein ganzes programm in try ... except ... end; setzt fürht ein Fehler am Anfang dazu, dass das ganze restliche Programm abgebrochen wird. Wenn du nur die unsicheren Stellen in einen Block setzt kann das restliche Programm noch weiterlaufen. Ich denke es kommt auf die Situation an.

MfG
freak

[Binärbaum]

Zitat:

Zitat von Speedmaster

Naja ich weiss nicht ob das nicht Sinnvoll wäre es doch so zu machen, da ja bald( 2006 ) der Cell Processor rauskommt wird die Geschwindigkeit weniger ein Problem sein, allerdings hat man dann ein Programm was Praktisch "ohne Fehler" läuft( B.z.w. sie werden alle abgefangen ).

Zwei Gegenargumente:
1. Es wird wohl kaum jeder diesen Prozessor haben/kaufen wollen.
2. Es sollte garnicht erst dazu kommen, dass Fehler abgefangen werden müssen. Das kann man z.B. durch eine Beschränkung der zulässigen Eingabewerte erreichen. Und wenn eine Exception abgefangen wird, wird der Code nach der Exception garnicht mehr ausgefürt, da sofort in den except-Teil gesprungen wird. Und wenn der fehler schon in den ersten Zeilen des Codes auftritt, ist der Rest quasi für die Katz.

MfG
Binärbaum

[Speedmaster]

Nicht umbedingt, wenn du die Exceptions selber auslößt und erstellst( Gibt zwar viele exceptions dann aber egal ) hast du bei Vernünftigem Code doch eine recht gute Übersicht über die Fehlerquelle!

Um das Programm weiterlaufen zu lassen gibt es ja auch noch die Möglichkeit an bestimmten Stellen zusätzliche Blöcke zu setzen, oder das ganze in eine While Schleife zu Packen. Solange du die Variablen nicht Freigibst sind die Aktuellen Programmvariablen auch noch erhalten!

@Binärbaum: Warum sollte niemand den Prozessor kaufen wollen??

[sECuRE]

Hi,

Zitat:

Zitat von Speedmaster

Naja ich weiss nicht ob das nicht Sinnvoll wäre es doch so zu machen, da ja bald( 2006 ) der Cell Processor rauskommt wird die Geschwindigkeit weniger ein Problem sein, allerdings hat man dann ein Programm was Praktisch "ohne Fehler" läuft( B.z.w. sie werden alle abgefangen ).

Hehehe. Sag sowas nicht. Nicht jeder wird auf 'nen Cell umsteigen. Und wenn du jetzt schon gut und performant programmierst, wird es auf 'nem Cell-Prozessor NOCH schneller laufen. Think positive ;)

cu

[Speedmaster]

Kann hier jemand sagen wie gross der Geschwindigkeitsverlust ist?

[Binärbaum]

Zitat:

Zitat von Speedmaster

@Binärbaum: Warum sollte niemand den Prozessor kaufen wollen??

War etwas ungünstig ausgedrückt, aber das meinte ich nicht damit. Es war eher so gemeint, wie es auch im Beitrag von sECuRe angeklungen ist.
Nicht jeder wird sofort auf Cell umsteigen.

[Tyrael Y.]

Der Prozessor ist doch schei...al ups sry ^^....

Gut programieren wollen wir, oder?

Dann sollte man auch um jede Stelle die eine mögliche Feherquelle ist einen try except bauen...

..wer das nicht macht und große Projekte durchführt wird noch ein blaues Wunder erleben

Zur Geschwindigkeit siehe meinen letzen Post

mfg

[Binärbaum]

Zitat:

Zitat von Tyrael Y.

Der Prozessor ist doch schei...al ups sry ^^....

Gut programieren wollen wir, oder?

Dann sollte man auch um jede Stelle die eine mögliche Feherquelle ist einen try except bauen...

Ja, gut programmieren wollen wir. Aber try...except ist nicht die optimale Lösung. Die optimale Lösung ist, einen Code zu schreiben, bei dem an der betreffenden Stelle erst gar kein Fehler/Exception auftritt. Und erst wenn das nicht möglich oder nur mit unverhältnismäßig großem Aufwand realisierbar ist, dann kannst du try..except nehmen.

MfG
Binärbaum