Schleifenabbruch durch exception verhindern

[himitsu]

Finally wird immer verarbeitet und wenn man zwischen Finally und End eine aktuell eventuell vorhandene Exception verwirft, dann hätte man auch jetzt schon sein Try-Finally&Except.
Wenn man nur prüfen will, ob eine Exception auftrat, um diese eventuell zu loggen, aber nicht um sie zu behandeln, dann reicht ebenfalls ein Try-Finally und ein 22-buchstabiger Befehl.

Aber ja, um 2-3 Zeilen und eine Ebene in der Einrückung zu sparen, wäre ein Try-Finally-Except-End, bzw. Try-Except-Finally-End bestimmt ganz nett.

[BadenPower]

Zitat von himitsu:

Aber ja, um 2-3 Zeilen und eine Ebene in der Einrückung zu sparen, wäre ein Try-Finally-Except-End, bzw. Try-Except-Finally-End bestimmt ganz nett.

Dann aber auch noch gleich ein echtes ELSEIF, welches ich persönlich sehr vermisse.

[Sir Rufo]

Das try ... except ... finally ... end ist doch nur was für Leute mit Exception-Phobie

[himitsu]

Zitat von BadenPower:

Dann aber auch noch gleich ein echtes ELSEIF, welches ich persönlich sehr vermisse.

Du mein ein CASE-OF?

Ja, ein CASE für nicht-ordinale Typen wäre bestimmt auch nett.
Und dann noch nicht-konstante Werte im CASE.

Das ist ja nicht so ganz der Renner:

Delphi-Quellcode:

case IndexStr(S, ['aaa', 'bbb', 'ccc']) of
  0{aaa}: ...;
  1{ddd}: ...;
  2{ccc}: ...;
end;

[Sir Rufo]

Also ein case mit variablen oder nicht ordinalen Werten wäre zwar charmant, aber zu welchem Preis?

Einige Fehler finde ich erst zur Laufzeit (z.B. ein Wert ist doppelt vorhanden). Da macht es schon eher Sinn sich einen solchen Case als Klasse mit Closures/Methoden zusammenzubauen. Man benötigt eine Factory-Klasse was daraus ein Closure baut.

Delphi-Quellcode:

var MyCase : TProc<string>;

MyCase := TCaseFactory<string>
  .Case( 'foo', procedure begin ShowMessage( 'Moin' ); end )
  .Case( 'bar', procedure begin Application.MainForm.Close; end )
  .Else( procedure begin end )
  .Build;

MyCase( 'bar' );

[BadenPower]

Zitat von himitsu:

Zitat von BadenPower:

Dann aber auch noch gleich ein echtes ELSEIF, welches ich persönlich sehr vermisse.

Du mein ein CASE-OF?

Nein, eigentlich nicht, sondern ein IF-ELSEIF-ELSE.

Delphi-Quellcode:

if (Bedingung1) then
 begin
  ...
 end
elseif (Bedingung2) then
 begin
  ... 
 end
elseif (Bedingung3) then
 begin
  ...
 end
else
 begin
  ...
 end;

Als bekennender "Begin-End"- und Einrückungsfetischist sieht das nämlich immer so aus:

Delphi-Quellcode:

if (Bedingung1) then
 begin
  ...
 end
else
 begin
  if (Bedingung2) then
   begin
    ...
   end
  else
   begin
    if (Bedingung3) then
     begin
      ...
     end
    else
     begin
      ...
     end;
   end;
 end;

Und jetzt stell Dir vor Du musst 10-15 Bedingungen prüfen.

[Dejan Vu]

Lustig, das Niemand was an diesem 1000 Zeilen Monstrum auszusetzen hat.

Mein Tipp wäre: Anstatt den Fehler fürs Erste zu ignorieren, und für 'try...finally...except..end' (oder umgekehrt) zu voten, oder mit anderen Nice-To-Have-Features zu liebäugeln, würde ich mal das Refaktoring-Beil herauskramen.

Deine Klasse ist zu komplex und das hast du nun davon.

Delegiere Teile der Funktionen deiner Klasse in andere (neue) Klassen.
Gruppiere Methoden in deiner Riesenklasse, die gemeinsame private Variablen verwenden und lagere sie aus.
Wenn eine Methode viele andere Methoden aufruft, wäre das auch ein Kandidat für eine eigene Klasse.

Dabei räumst Du auf und vielleicht findest Du den Fehler dann. Wenn nicht, dann prüfe einfach die einzelnen Methoden und schreibe Unittests.

[himitsu]

Über die 1000 Zeilen hatte man sich bereits auf Seite 1 aufgeregt.

Als bekennender "Keine unnötigen Klammern oder Begin-End und Bedin-End in selber Zeile"-Fetischist kann ich das Problem nicht erkennen.

Delphi-Quellcode:

if Bedingung1 then
  ...
else if Bedingung2 then
  ...
else if Bedingung3 then
  ...
else
  ...;

if Bedingung1 then begin
  ...
end else begin
  ...
end;

[Uwe Raabe]

Zitat von Dejan Vu:

Lustig, das Niemand was an diesem 1000 Zeilen Monstrum auszusetzen hat.

Natürlich wäre das der korrekte Ansatz. Allerdings steht ausdrücklich im ersten Post:

Zitat von bernhard_LA:

Technisch bekomme ich dieses Problem nicht schnell gelöst.

Ich gehe also davon aus, daß dieser (obwohl bessere) Weg hier aus Zeitgründen nicht eingeschlagen werden kann oder soll.

[Dejan Vu]

Ich glaube, das man hier vor lauter Wald den Baum nicht sieht. Bugs in so einem Klassenmonstrum kann man i.A. "technisch nicht schnell" lösen.

Da ich aber auch darauf poche, den Eingangspost zu lesen und den TE ernst zu nehmen, muss das akzeptieren. Danke für den Hinweis.