Ich habe bisher immer darauf geachtet, dass meine Programme so wenige Fehler, wie moeglich enthalten.
Je nachdem, wie gross das Projekt wird verliert man jedoch auch oft die Uebersicht, da es Schleifen gibt, die je nach Benutzereingabe auf tausend Verschiedene Art und Weisen reagieren koennen.
Mein Fazit darauf war: Wenn man keinen IQ von 300 hat gibt es in jedem komplexeren Programm immer Fehler.
Ganz besonders dann, wenn es um Arrays, ihren Index und tausende von Abstraktionen geht.

Ich habe mir nun ueberlegt, dass ich in meinem momentanen Projekt alle kritischen Stellen in ein Try - Catch packe und die Fehler einfach verschlucke, die auftreten.
Selbstverstaendlich heisst das nicht, dass ich mir keine Gedanken mehr um das machen will, was ich programmiere.
Aber es ist doch besser als dem Enduser ein Programm zu schreiben, was bei einer falschen Eingabe gleich abstirbt, weil dieser eine bestimmte Fall eventuell nicht beruecksichtigt war.

Ich wollte euch aber zuerst jetzt mal fragen, wie ihr das macht.
Wie geht ihr mit Fehlerbehandlung und ganz besonders mit dem sagenumwobenen Try-Catch um?

Wie oft verwendet ihr es?
Haltet ihr es fuer Sinnvoll es immer zu verwenden, wenn in Schleifen auf die Elemente von sequenziellen Kontainern zugegriffen wird, wo alle moeglichen Dinge passieren koennen?

Wie sehr ihr das?
Kennt ihr eventuell einen Abschnitt, der sich damit beschaeftigt?

Vielen Dank fuer alle eure Antworten.

David

Ich habe mir nun ueberlegt, dass ich in meinem momentanen Projekt alle kritischen Stellen in ein Try - Catch packe und die Fehler einfach verschlucke, die auftreten.

Einfach verschlucken - ist das nicht eine der Methoden, die Apple ganz gerne anwendet, damit der Benutzer nur keine Fehlermeldung sieht?

Als ich das letzte Mal jemandem dabei helfen durfte, über iTunes ein iPhone und Outlook 2003 zu synchronisieren, bekam ich immerhin eine "Es trat ein Fehler auf."-Nachricht. Anscheinend mutet Apple Windows-Benutzern wenigstens generische Fehlermeldungen zu.

777 schrieb:

Aber es ist doch besser als dem Enduser ein Programm zu schreiben, was bei einer falschen Eingabe gleich abstirbt, weil dieser eine bestimmte Fall eventuell nicht beruecksichtigt war.

Als Anwender mag man sich über eine kryptisch anmutende Meldung ärgern, aber der Entwickler (also du) sollte froh sein, einen etwas ausführlicheren Bugreport als "das Programm stürzte ab" bekommen zu können.

777 schrieb:

Ich wollte euch aber zuerst jetzt mal fragen, wie ihr das macht.
Wie geht ihr mit Fehlerbehandlung und ganz besonders mit dem sagenumwobenen Try-Catch um?

Wie oft verwendet ihr es?

In Windows-Anwendungen so gut wie überhaupt nicht. Das UI-Framework (VCL) fängt Exceptions, die in Event-Handlern auftreten - und so ziemlich jede potentiell fehlerträchtige Situation wird über einen solchen induziert - und zeigt dem Benutzer die Fehlermeldung (Exception::Message oder auch std::exception::what()) an. Mit geeigneten 3rd-Party-Plug-ins kann man auch einen Stacktrace generieren und als Bugreport versenden lassen.

...

Es gibt dazu was im Magazin. Shade hat dazu auch noch ein paar gute Artikel fürs Magazin verfasst. Die findest Du hier und hier.

Ich wollte euch aber zuerst jetzt mal fragen, wie ihr das macht.
Wie geht ihr mit Fehlerbehandlung und ganz besonders mit dem sagenumwobenen Try-Catch um?

Exceptions haben nicht das Ziel, Programmierfehler wieder gut zu machen. Die musst du schon vorher beheben.

Vielmehr können damit unerwartete Laufzeitfehler signalisiert werden. Beispielsweise, wenn eine Ressource nicht geladen werden kann (z.B. Datei). Oder wenn eine Funktion nicht in der Lage ist, ihre Arbeit wie gewollt zu erledigen. Oder wenn ein Objekt nicht konstruiert werden kann. Oder... Der Indexzugriff auf Container ist ein Streitfall. Du kannst natürlich den Benutzer direkt zugreifen lassen, z.B. so:

std::vector<int> Vec;
int Index;
std::cin >> Index;

try
{
    std::cout << Vec.at(Index);
}
catch (std::out_of_range& e)
{
    std::cout << "Fehlerhafter Index.";
}

Aber gut ist das nicht wirklich. Die Eingabe sollte sowieso geprüft werden. Tatsächlich kommt es auch selten dazu, dass der Benutzer direkt einen Index angeben muss, auf den er zugreift.

777 schrieb:

Haltet ihr es fuer Sinnvoll es immer zu verwenden, wenn in Schleifen auf die Elemente von sequenziellen Kontainern zugegriffen wird, wo alle moeglichen Dinge passieren koennen?

Wenn alle möglichen Dinge passieren können, hast du etwas falsch gemacht. Wie meinst du das konkret? Du solltest dir schon im Klaren darüber sein, was passieren kann. Und gegebenenfalls Fehler (die zur Laufzeit entstehen) ordentlich zu behandeln.

Wie geht ihr mit Fehlerbehandlung und ganz besonders mit dem sagenumwobenen Try-Catch um?

Fehlerbehandlung kann sehr einfach sein, wenn du dir igendwie dokumentierst, welche Fehler wann wo auftreten können und wie sie behandelt werden. Bei eigenen und/oder kleinen Projekten kann eine simple Textdatei reichen. Dabei sollte man sich erst überlegen, wie man den Fehler behandelt, dann einen Satz mit der passenden Stellenangabe in die Textdatei schripseln und anschließend die Fehlerbehandlung einbauen. Ist wirklich nicht viel Arbeit, nicht mal eine Minute pro Fehler, der auftreten kann und man nimmt der Fehlerbehandlung ihre komplette Undurchsichtigkeit, die sie typischerweise hat.
Beispiel:

- Fehlerbehandlung -

- Beim Startup des Programms wird versucht, die Config-Datei zu laden (main.cpp, Funktion "Init"). Wenn das schiefgeht, default-Config-Datei anlegen, keine Warnung ausgeben.

- Im Dialog "Datei konvertieren" wird im Editfeld (ID_EDIT_123) ein Pfad angegeben. Bei einem Klick auf OK (ConvertDlg.cpp, OnOkClicked) wird
die Datei geladen. Wenn sie nicht gefunden oder geöffnet werden kann, wird eine Message-Box gezeigt und die OK-Aktion abgebrochen.

Natürlich ist das nicht geeignet für z.B. Index-Überschreitungs-Exceptions, aber von denen halte ich eh nicht viel. Da verlasse ich mich eher auf asserts, Crashs und vom Debugger erkannte Heap-/Stack-Corruptions.

Beispiel:

- Fehlerbehandlung -

- Beim Startup des Programms wird versucht, die Config-Datei zu laden (main.cpp, Funktion "Init"). Wenn das schiefgeht, default-Config-Datei anlegen, keine Warnung ausgeben.

- Im Dialog "Datei konvertieren" wird im Editfeld (ID_EDIT_123) ein Pfad angegeben. Bei einem Klick auf OK (ConvertDlg.cpp, OnOkClicked) wird
die Datei geladen. Wenn sie nicht gefunden oder geöffnet werden kann, wird eine Message-Box gezeigt und die OK-Aktion abgebrochen.

lol
das wird kein mensch durchhalten. code und fehlerbehandlungsvorhabensbeschreibungsdatei divergieren.
statt solche vorhaben vorzuhaben und dir vorsätze vorzusetzen, solltest du die fehler einfach behandeln.

das wird kein mensch durchhalten. code und fehlerbehandlungsvorhabensbeschreibungsdatei divergieren.

Wenn in diesem Detailgrad, ja. Lässt sich bei mehr dann aber auch einiges zusammenfassen oder allgemeiner fassen und eine Doku zur Fehlerbeschreibung ist nunmal Gold wert.

Doku zur Fehlerbeschreibung ist nunmal Gold wert.

nö.

volkard schrieb:

das wird kein mensch durchhalten. code und fehlerbehandlungsvorhabensbeschreibungsdatei divergieren.

Wenn in diesem Detailgrad, ja. Lässt sich bei mehr dann aber auch einiges zusammenfassen oder allgemeiner fassen und eine Doku zur Fehlerbeschreibung ist nunmal Gold wert.

Im Prinzip ja, nur schreibt man in die Doku:

/**
...
 \throws IOException
...
*/
void loadConfig(string const& path) {
...
}

und nichts anderes...

[code]
- Beim Startup des Programms wird versucht, die Config-Datei zu laden (main.cpp, Funktion "Init"). Wenn das schiefgeht, default-Config-Datei anlegen, keine Warnung ausgeben.
[(code]

void Init()
{
...
   if(!loadConfig("user.ini"))
      if(!loadConfig("default.ini"))
         throw fileNotFoundError("default.ini");
...
}

vermutlich die drei zeilen in eine eigene funktion stecken, damit die Init klarer wird.
dein absichtsdatei legt sogar fest, daß nicht ausgelagert wird und daß die funktion Init in der main.cpp bleiben soll.

Badestrand schrieb:

Doku zur Fehlerbeschreibung ist nunmal Gold wert.

nö.

*seufz* Alleine schon, weil Fehlerbehandlung (wenn man die Mikro-Ebene ausschließt) das Verhalten der Software bestimmt und Verhalten dokumentiert gehört.

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. Meiner Meinung nach muss man eindeutig festschreiben, wann die Software wie zu reagieren hat. Eben auch bei Fehlerbehandlung.

volkard schrieb:

dein absichtsdatei legt sogar fest, daß nicht ausgelagert wird und daß die funktion Init in der main.cpp bleiben soll.

Das Beispiel ist (wie auch geschrieben) nur für eigene (wo's egal ist) und sehr kleine Projekte gedacht. Die Stellenangabe sollte nur den aktuellen Standort festhalten, kann man natürlich machen wie man will.

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. Meiner Meinung nach muss man eindeutig festschreiben, wann die Software wie zu reagieren hat. Eben auch bei Fehlerbehandlung.

Äh. Dann hast du Exceptions nicht verstanden.

loadConfig _darf_ nicht wissen wie es auf einen Fehler reagiert. Die Verantwortung hat der Caller.

Das Beispiel ist (wie auch geschrieben) nur für eigene (wo's egal ist) und sehr kleine Projekte gedacht. Die Stellenangabe sollte nur den aktuellen Standort festhalten, kann man natürlich machen wie man will.

Das bedeutet doppelte Arbeit: Programmierer muss Code und Doku ändern ohne dass sich etwas relevantes geändert hat.

Furchtbar sowas. Sowas führt zu unwartbarem Code. Hatte da mal ein Projekt übernommen wo die Doku sehr genau war und der Code schlecht. Das Problem dabei war nun dass der Code sich anders verhalten hat als die Doku...

Ne ne ne. Bloss nie nie nie 2 parallele Code Basen führen. Die laufen async. Und zwar garantiert.

Es gibt veraltete Ansätze wo man versucht über Doku schlechten Code wettzumachen - aber das führt einfach nicht zum Ziel. Doku muss den Code ergänzen und darf ihn nie nie nie selber definieren.

Vorallem da es unterschiedliche Leute sind die loadConfig schreiben und die die es aufrufen. Sind ja uU sogar andere Firmen. Wie kann der loadConfig programmierer das wissen haben? Kann er eben nicht. Deshalb: loadConfig wirft ne exception oder returned einen Wert wenn die Config nicht geladen werden kann.

Denn zB wenn ich
foo --with-config=config.cfg
mache dann muss es ein Fehler sein
wenn ich aber
foo
mache dann muss er die default.cfg laden.

Der richtige Platz das zu dokumentieren ist in der CLI Doku für den Enduser und uU in den internen style guidelines.

aber sicher nicht in der code doku.

Aber ich danke euch dennoch fuer eure Antworten und werd mal sehn, was ich daraus machen kann...werde.

Shade Of Mine schrieb:

Der richtige Platz das zu dokumentieren ist in der CLI Doku für den Enduser und uU in den internen style guidelines.

Jein. In die Doku für den Endnutzer braucht natürlich nur das rein, was ihn auch angeht und überhaupt betrifft.

Kleines Beispiel, wo mich fehlende Fehler-Doku genervt hat: Auf mehrere Computer verteilte Berechnungen, ein Durchlauf dauert etwa 3 Wochen. Es gibt unheimlich viele Fehlerquellen und öfters kommt der Durchlauf nicht zu Ende, im schlimmsten Fall wird nach 2,5 Wochen eine Exception geworfen, die den Lauf beendet. Jetzt wollte ich natürlich stärkere Exception-Toleranz einbauen, z.B. durch Ignorieren (mit späterem Nutzer-Report), Wiederholen, Korrekturen versuchen, Rollbacks, ggf Nutzerinteraktion usw. 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. 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.

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.

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

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.

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 uncatched Exceptions

uncatched steht nicht im wörterbuch.

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).

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.

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.

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.

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