Try Except Problem

[himitsu]

Jupp, das hab ich bei einigen Codes auch schon gemacht.

Leider gibt es IfOpt nur für die alten einbuchstabigen "+/-"-Optionen. :cry:


Einfach so umschalten und danach "zurückschalten" ist einfach nur falsch, vorallem wenn man sich vorher nicht den aktuellen Zustand merkt und danach "wirklich" wiederherstellt.
Leider fehlt auch noch eine Push/Pop-, bzw. Save/Restore-Möglichkeit, für die Compilerschalter.

Sowas wäre ja toll,

Delphi-Quellcode:

{$PUSH Options}  // oder {$PUSH Option X}
{$X+}
machwas;
{$POP Options}

bzw.

Delphi-Quellcode:

{$SAVEOPT X}
{$X+}
machwas;
{$RESTOREOPT X}

aber die Realität sähe etwa so aus :wall:

Delphi-Quellcode:

{$IFOPT X+} {$DEFINE _SaveX} {$ELSE} {$UNDEF _SaveX} {$ENDIF}
{$X+}
machwas;
{$IFNDEF _SaveX} {$X-} {$ENDIF}

denn

Delphi-Quellcode:

{$X+}
machwas;
{$X-}

wäre halt sowas von total falsch, wenn das X vorher schon aktiviert war und es danach nicht mehr ist. :warn:

[BUG]

Zitat:

Zitat von himitsu (Beitrag 1288517)

aber die Realität sähe etwa so aus :wall:
[DELPHI]{$IFOPT X+} {$DEFINE _SaveX} {$ELSE} {$UNDEF _SaveX} {$ENDIF}

Oder eben:

Delphi-Quellcode:

{$I StoreOptions}
{$X+}
// Zeug
{$I LoadOptions}

Die Includes müsste man nur einmal schreiben :mrgreen:
Aber stimmt schon, ein richtiger eingebauter Optionsstack wäre natürlich besser.

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1288510)

Wenn irgendein Idiot daran rumspielt, dann hat er Pech und muß mit den Konsequenzen leben.
Ich bin auch dafür, daß solche Optionen endlich mal aus den Projektoptionen raus fliegen oder es zumindestens mit mindestens 200 "Willst du das wirklich?"-Dialogen bestätigen muß.

Ich habe mittlerweile einige Projekte gesehen, bei denen das absichtlich als Standard gesetzt war.
Aber welche anderen Einstellungen bringen denn die Logik potentiell so durcheinander, dass es tragisch wäre, wenn die anders gesetzt sind als erwartet? Da fallen mir ehrlich gesagt auf Anhieb keine ein.

[JamesTKirk]

Zitat:

Zitat von himitsu (Beitrag 1288517)

Einfach so umschalten und danach "zurückschalten" ist einfach nur falsch, vorallem wenn man sich vorher nicht den aktuellen Zustand merkt und danach "wirklich" wiederherstellt.
Leider fehlt auch noch eine Push/Pop-, bzw. Save/Restore-Möglichkeit, für die Compilerschalter.

Dann ist ja gut, dass bei diesem Thread Free Pascal drüber steht. Da geht das nämlich:

Delphi-Quellcode:

{$PUSH}
{$X+}
machwas;
{$POP}

:mrgreen:

Gruß,
Sven

[Dejan Vu]

Zitat:

Zitat von jaenicke (Beitrag 1288521)

Aber welche anderen Einstellungen bringen denn die Logik potentiell so durcheinander, dass es tragisch wäre, wenn die anders gesetzt sind als erwartet? Da fallen mir ehrlich gesagt auf Anhieb keine ein.

Wenn Du vollständige Bool'sche Evaluation meinst:

Delphi-Quellcode:

if CalculateFunctionWithSideEffec1 or CalculateFunctionWithSideEffec2 then

Klar, wer ist so dämlich... aber es ging ja nur ums einfallen.

[jaenicke]

Zitat:

Zitat von Dejan Vu (Beitrag 1288525)

Wenn Du vollständige Bool'sche Evaluation meinst:

Nein, ich meinte andere Einstellungen als eben die vollständige boolsche Auswertung. Klar, wenn man z.B. RTTI Informationen ausklammert, gibt es auch potentiell Fehler, aber das ändert erst einmal nichts an der Programmlogik.

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1288447)

Delphi-Quellcode:

try
  i := StrToInt('abc');
except
  i := 0;
end;

@nicht nur Himitsu
Wenn die 0 als Fehler definiert ist und alle Datensätze gelesenwerden müssen, egal ob gültig oder nicht, und die Anwendung nicht dialoglastig ist, dann ist so ein Konstrukt nicht ganz falsch.

Gruß
K-H

[himitsu]

Doch, ist es.

Versuch mal soeinen Code zu debuggen :freak: und außerdem sind Exceptions eher für Ausnahmen und nicht zur "normalen" Programmsteuerung gedacht.
Val, TryStrToInt, StrToIntDef usw.

[Sir Rufo]

Zitat:

Zitat von p80286 (Beitrag 1288559)

Zitat:

Zitat von himitsu (Beitrag 1288447)

Delphi-Quellcode:

try
  i := StrToInt('abc');
except
  i := 0;
end;

@nicht nur Himitsu
Wenn die 0 als Fehler definiert ist und alle Datensätze gelesenwerden müssen, egal ob gültig oder nicht, und die Anwendung nicht dialoglastig ist, dann ist so ein Konstrukt nicht ganz falsch.

Gruß
K-H

Ja wenn die Welt so einfach wäre ... und niemand diese Funktion anders definieren könnte, dann ja, aber dem ist nicht so, da diese Funktion eben doch auf einmal aus einer anderen Unit kommt, dort fehlerhaft ist und eigentlich eine Exception wirft und ich diese Information nie bekomme, weil ich toll alle Exceptions wegfange.

Niemals eine Exception blind wegfangen, sondern eher an so vielen Stellen wie möglich sogar eine Exception werfen, wenn die übergebenen Informationen so nicht verarbeitbar sind. Nur so kann ich eine zuverlässige und robuste Anwendung erstellen mit möglichst wenigen Bugs.

[mm1256]

Zitat:

Zitat von Sir Rufo (Beitrag 1288608)

Niemals eine Exception blind wegfangen, sondern eher an so vielen Stellen wie möglich sogar eine Exception werfen, wenn die übergebenen Informationen so nicht verarbeitbar sind. Nur so kann ich eine zuverlässige und robuste Anwendung erstellen mit möglichst wenigen Bugs.

Wahre Worte und mir aus der Seele gesprochen :thumb: