Try - Catch
-
Badestrand, nimm mal die Rosa-Doku-Brille ab.
Nichts ist schlimmer als vom Code getrennte Dokumentation.
-
hustbaer schrieb:
Nichts ist schlimmer als vom Code getrennte Dokumentation.
Definitiv. Ist aber kein allzu großes Problem, wenn die Auflistung von möglichen Fehlerfällen und deren Behandlung abstrakt genug ist.
-
Badestrand schrieb:
hustbaer schrieb:
Nichts ist schlimmer als vom Code getrennte Dokumentation.
Definitiv. Ist aber kein allzu großes Problem, wenn die Auflistung von möglichen Fehlerfällen und deren Behandlung abstrakt genug ist.
Natürlich. Bloss Papier ist geduldig. Und irgendwelche Text-Files oder sonstige Dokumente die irgendwo rumliegen sind genauso geduldig.
Nur weil in "Error handling rules for project XYZ.txt" irgendwas drinnen steht, heisst das noch lange nicht dass es auch so ist
-
Badestrand schrieb:
Shade Of Mine schrieb:
\throws IOException
und nichts anderes...Achtlos. Dann hast du nämlich keine Ahnung, wie oder ob überhaupt darauf reagiert wird. Typisch Exceptions - du gibst einfach die Verantwortung ab und am Ende hat sie keiner.
Typisch uncatched Exceptions, bei denen übernimmt nur das OS die Verantwortung indem es dien Programm terminiert. Bei catched Exceptions bekommst du nen Compileerror und musst die Verantwortung übernehmen, aber weil ne ganze Menge schlechter Javaprogrammierer die Verantwortung schlecht übernommen hat, gelten die jetzt auch als schlecht.
-
Edit: Man ersetze *catched duruch *checked
Typisch unchecked Exceptions, bei denen übernimmt nur das OS die Verantwortung indem es dien Programm terminiert. Bei checked Exceptions bekommst du nen Compileerror und musst die Verantwortung übernehmen, aber weil ne ganze Menge schlechter Javaprogrammierer die Verantwortung schlecht übernommen hat, gelten die jetzt auch als schlecht.
-
Typisch dummes Kommentar.
-
kugelecke schrieb:
Typisch uncatched Exceptions
uncatched steht nicht im wörterbuch.
-
Badestrand schrieb:
Natürlich kann das nicht bei Libraries oder einzelnen Funktionen passieren, sondern im Gesamtkontext der Software. Es soll also nicht zu der Funktion "LoadConfig" dokumentiert werden, wie die Ausnahme behandelt wird, sondern global.
Das essentielle ist aber, dass loadConfig eine IOException wirft. Je nach Kontext aus dem loadConfig aufgerufen wird muss der Fehler anders behandelt werden.
Wenn du aber jede Funktion die einen Fehler verursachen kannst extra dokumentieren willst - ne das hoffe ich mal nicht.
Was dagegen Sinn machen kann ist zu sagen "Wenn das Starten der Anwendung nicht möglich ist, dann schreib einen syslog eintrag" oder derartiges. Aber dann bist du eh wieder so abstrakt dass das mit dem Code selber ja nichts mehr zu tun hat - das ist dann einfach die Doku des Programmverhaltens.
Ohne Doku hast du aber keinen Überblick, was in den tausenden von Zeilen alles an Ausnahmen auftauchen können, also musst du Großteile des Codes durchgehen und dir alle Fehlerfälle zusammenklauben um für sie jeweils einen passenden Ausnahmeweg zu konstruieren, was einfach verflucht viel Arbeit ist.
Dafür hast du ja die Code Dokumentation: calcX wirft X, Y und Z exceptions.
uU willst du eher sowas wie Javas checked exceptions?
Mit Doku hättest du eben eine Übersicht, welche Ausnahmen auftreten können und wie und wo sie momentan behandelt werden. Und ja, die Schattenseite einer Dokumentation ist immer ihre Aktualität, dafür kann sie enorm viel Arbeit ersparen.
Ich bin ja _für_ doku aber keine parallele sondern eine Code Doku und das ist auch genau das was dir hier geholfen hätte mit automatisierungen.
Meistens reicht aber ein catch(exception& e) aus, da dich der genaue Fehler idR eh nicht interessiert. Viel interessanter ist es dagegen rauszufinden wo du die neustarts ansetzen musst.
Wenn du das weisst, kannst du mit automatischen tools dir alle exceptions anzeigen lassen die da geworfen werden können (wenn du eine ordentliche doku hast).
-
Shade Of Mine schrieb:
Wenn du das weisst, kannst du mit automatischen tools dir alle exceptions anzeigen lassen die da geworfen werden können (wenn du eine ordentliche doku hast).
Also ein Tool, dass das kann, was ein Compiler bei checked Exceptions kann, sogar wenn die Doku schlecht ist oder einen Tippfehler hat. Also falls einer mal throwed statt throws oder catched statt checked schreibt - soll so Leute geben.
-
kugelecke schrieb:
Also falls einer mal throwed statt throws oder catched statt checked schreibt - soll so Leute geben.
Deshalb bekommst du eine Warnung von doxygen wenn du einen unbekannten tag angegeben hast...
das zauberwort heisst hier: automatisierung
dann existieren solche probleme garnicht erst.
-
kugelecke schrieb:
Also falls einer mal throwed statt throws oder catched statt checked schreibt - soll so Leute geben.
da macht man erstmal
#define throwed thrown
#define catched caught
oder sowas. die ganzen ausländischen wörter kann man sich ja gar nicht merken.
und sucht dann erst weiter.
-
Shade Of Mine schrieb:
kugelecke schrieb:
Also falls einer mal throwed statt throws oder catched statt checked schreibt - soll so Leute geben.
Deshalb bekommst du eine Warnung von doxygen wenn du einen unbekannten tag angegeben hast...
das zauberwort heisst hier: automatisierung
dann existieren solche probleme garnicht erst.
Genau, automatisch vom Compiler geprüft.
volkard schrieb:
#define catched caught
#define catched checked :p
