Exception vs. error number

[hoika]

Hallo #,

mal ne Grundfrage ;)

Ich weiss, man sollte für Fehlermeldungen / -erkennung
Exceptions benutzen.
Nun ist es aber so, dass beim Debuggen einem dann ein Haufen
Exceptions um die Ohren fliegen.

Klar könnte man die auch gezielt über die IDE ausblenden,
aber das ist ja ein Haufen Fummelei.


Wie geht ihr bei Exceptions vor.
Sowas wie "stille Exceptions" gibt es ja nicht (?).
Und sowas wie IFDEF DEBUG und damit Exceptions auszuschalten,
ist ja auch nicht fas Wahre.


Heiko

[sirius]

Was ist jetzt daran so schlimm, spezielle Exceptions beim Debuggen auszuschalten?

[himitsu]

also mein Vorgehn ist recht einfach und Wirkungsvoll:

einfach möglichst keine Exceptions auftreten lassen.


vorallem da wo man schön mit dr WinAPI arbeiten kann, statt den "unperformaten/überladenen" Delphidingern ... die kennent sowas nicht und arbeitet stattdessen mit Rückgabewerten (z.B. Fehlernummern im Result) und oftmals mit sowas wie GetLastError (wenn nur True/False zurückgegeben wird).

Aber am Besten ist es das Auftreten des Fehlers, welcher z.B. zur Exception führt vorher abzufangen und diesen garnicht erst auftreten zu lassen.


Drum hab ich ja auch genügend Programme die ohne Try-Finally/Except auskommen ... siehe mein FileSplitter.
> richtiger Zugriff + keine "unbehebbaren" Fehler = keine Exceptions


OK, man könnte auch über die System-Unit die Exceptionbehandlung umbiegen und beim Debuggen auf "stumm" schalten (auf 'ne im Debugger nicht angezeigte Exception umleiten), aber da ist es mit Sicherheit besser die unerwünschten Exceptions im Debugger einfach abzustellen.

[QuickAndDirty]

Exceptions gibt es z.B. damit man auf so sachen wie
"Goto Error" verzichten kann.
Des weiteren wird ersparen Exceptions arbeit. Wenn du Z.B. Parameter hast die selbst Funktionen sind

Delphi-Quellcode:

Rechne(Inttostr(n),strtoint(s));

Ein fehler code macht das etwas unschön. Try except geht.

Wo ich wirklich zustimmen muss ist das das Debuggen mit Exceptions einfach nervt.
Würde mir Wünschen das man z.b. dem debugger sagen kann er solle nur eine code einer bestimmten unit
debuggen....(Breakpoint auf alle Zeilen quasi)

[himitsu]

Zitat:

Zitat von QuickAndDirty

Exceptions gibt es z.B. damit man auf so sachen wie
"Goto Error" verzichten kann.
Des weiteren wird ersparen Exceptions arbeit. Wenn du Z.B. Parameter hast die selbst Funktionen sind

Delphi-Quellcode:

Rechne(Inttostr(n),strtoint(s));

Ein fehler code macht das etwas unschön.

ja aber gerade dann weißt du nicht mehr wo der Fehler aufgetreten ist ... oder wie willst du jetzt z.B. dem Benutzer sagen welche der beiden Zahlen falsch war?

ich finde sowas sehr unschön:

Delphi-Quellcode:

try
  //formular mit tausenden Werten abfragen
  ...
except
  messagebox('hey du wichser ... irgendwo hast du was falsches eigegeben'#10
    + 'such mal schön danach und berichtige das gefälligst!');
end;

dann lieber ein/zwei Zeilen mehr Code, wo vorher die werte geprüft werden und wo man dem Benutzer nett sagt "Hey Schnucki, könntes du mal liebenswürdiger Weise den Wert "xyz" berichtigen?".

Zitat:

Zitat von QuickAndDirty

Wo ich wirklich zustimmen muss ist das das Debuggen mit Exceptions einfach nervt.
Würde mir Wünschen das man z.b. dem debugger sagen kann er solle nur eine code einer bestimmten unit
debuggen....(Breakpoint auf alle Zeilen quasi)

schau mal in die debugger-Optionen ... einfach abschalten, was nervt.

mit {$D-} oder {$DEBUGINFO OFF} kannst du auch die Debugger-Informationen aus gewünschten Units entfernen, dann springt der debugger da auch nicht mehr hin.


wenn du z.B. 'nen dutzend Units hast und Alle bis auf Eine/Zwei funktionieren, dann in die anderen/funktionieren dieses rein und du kannst in Ruhe die Eine... debggen.

Zitat:

Exceptions gibt es z.B. damit man auf so sachen wie
"Goto Error" verzichten kann.

Eben nicht ... Exceptions = Ausnahmen
Die sind sozusagen der letzte Ausweg, wenn nichts mehr geht.

ich geb's zu ... hier schwirrt auch noch irgendwo ein Programm rum, wo ich absichtlich Exceptios zur Programmsteuerung geworfen hab (Raise) ... aber für sowas würde dich eigentlich fast jeder Cheff feuern.

[ironie]
und hey, Exceptions kann man auch ganz geil als Rückgabwert mißbrauchen ... z.B. um etwas ohne Variable von einer ganz rekursiven und/oder tief verschachtelten stelle nach ganz weit oben zu übergeben und sofort direkt dahin zu springen
[\ironie]


[add]
zu StrToInt:
es gibt nicht umsonst sowas wie StrToIntDef und TryStrToInt

[RavenIV]

Also meine Meinung zu Exceptions:
Es ist ein Sprachelement, das man so wenig wie möglich einsetzen sollte.
In bestimmten Fällen geht es nicht anderst, aber meistens kann man der evtl. auftretenden Fehler vorher abfangen.

Gutes Beispiel ist StrToInt.
Hier kann man vorher prüfen, ob im String etwas "vernünftiges" drinsteht oder so vorbeugen, dass nur drinstehen kann, was man haben möchte.

Unerwartete Fehler (Exceptions empfohlen) sind z.B.
- Abbrechen der DB-Verbindung
- Problem beim Lesen von der Festplatte

Keine unerwarteten Fehler (kein Exceptionhandling nötig) sind z.B.:
- falsch aufgebaute SQL-Queries
- Typumwandlungen
- Bereichsgrenze überschritten

Mein Vorgänger hat in unserer Software fast jeden Furz per try..except abgefangen.
Ich habe recht viel Zeit investiert, um 90% der Exceptions zu eliminieren.
Aber der Code ist jetzt wieder um ein gutes Stück übersichtlicher und somit besser wartbar.

[Ghostwalker]

Neben einigen Artikeln im Netz, hat auch Nick Hodges von Codegear einen Artikel über dir richtige Verwendung von Exceptions geschrieben.

Dieser ist Hier zu finden. Wie ich finde, hat
er das ganze recht gut beschrieben.

[hoika]

Hallo,

aber z.B. hat sich CodeGear bei DBExpress ja von dem alten ErrorNo
verabschiedet und dafür wird jetzt komplett über Exception gearbeitet.

Die Sache mit dem Compiler-Schalter ist nicht so schön

"Wenn alle anderen units OK sind", ;)
Naja, das ist immer so ne Sache in Forms mit mind. einem if ;)


Heiko
PS: Also lasse ich das erst mal so mit den error numbers.

[sirius]

Zitat:

Zitat von hoika

Die Sache mit dem Compiler-Schalter ist nicht so schön

Wieso? Das verhindert es doch nur im Debugger, wenn du weist, dass hier und da mal eine Exception auftreten kann.
Ich habe auch lange gezögert, bis ich meine erste eigene Exception geworfen habe. Aber ich finde es hin und wieder sehr praktisch. Vor allem kann man in eine Exception-Klasse noch viel mehr reinlegen, als nur einen ErrorCode. Und wie sieht es denn aus, einer Funktion mehr als einen Rückgabewert zu geben oder extra noch eine Art getlasterror inkl. einer globalen Variable zu implementieren.

[angos]

hi,

ich kann himitsu nur zustimmen. schreib sauberen code, dass möglichst keine exceptions auftreten. ein gutes beispiel, was hier schon teilweise aufgeführt wurde, ist das strtoint... da hat delphi spätestens ab version 7 eine schöne neue funktion, die viel besser genutzt werden kann

Delphi-Quellcode:

StrToIntDef

.
ansonsten halt die werte so vorbelegen, dass eine exception komplett vermieden wird.

einen block mit

Delphi-Quellcode:

  try
    .....
  except
  end;

zu kapseln ist so ziemlich das unklügste. wenn da ein fehler mit folgewirkung eintritt sucht man sich tot...


gruß
ansgar