Exception vs. error number
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 |
Re: Exception vs. error number
Was ist jetzt daran so schlimm, spezielle Exceptions beim Debuggen auszuschalten?
|
Re: Exception vs. error number
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. |
Re: Exception vs. error number
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:
Ein fehler code macht das etwas unschön. Try except geht.
Rechne(Inttostr(n),strtoint(s));
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) |
Re: Exception vs. error number
Zitat:
ich finde sowas sehr unschön:
Delphi-Quellcode:
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?".
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; Zitat:
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:
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 |
Re: Exception vs. error number
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. |
Re: Exception vs. error number
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. |
Re: Exception vs. error number
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. |
Re: Exception vs. error number
Zitat:
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. |
Re: Exception vs. error number
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:
zu kapseln ist so ziemlich das unklügste. wenn da ein fehler mit folgewirkung eintritt sucht man sich tot...
try
..... except end; gruß ansgar |
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:49 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz