Error Handling unter C++

[xmarvel]

hi

Da ich zur Zeit an ein etwas grösseren Projekt arbeite kommt bei mir die Frage auf wie man die Fehlerbehandlung im Programm richtig bewerkställigt ?
Dazu habe ich mir die try .. catch Methode angeschaut nur irgendwie verstehe ich den Sinn nicht so ganz darin. :confused:
Mann muss ja immer noch die Rückgabewerte überpüfen und dann mit throw an die Catch Anweisung "werfen".
Nur dann könnte ich doch gleich ne Klasse schreiben mit einer Methode drin wo ich dann direkt die Methode aufrufe.
Also wie macht man es richtig bei etwas grösseren Projekten ?
Wie versteht man die try ... catch Methode richtig ? Welche Vorteile hat man davon ? Denn irgendein Sinn hat die Methode bestimmt nur ich sehe sie inmoment noch nicht. ;)
Wie bewerkställigt Ihr das ? Vielleicht gibt es ja noch bessere Konzepte.

MFG
xmarvel

[BeS]

Hallo,
also ich habe in C++ noch nie exceptions verwendet, kann deswegen dirkt zu C++ nichts sagen.
Allgemein ist die Idee das man wenn ein Fehler auftritt eine exception "wirft" und sie dann an irgendeiner Stelle wieder "auffängt" und entscheidet was damit zu machen ist. Der "Vorteil" soll sein, dass du nicht an jeder Stelle wo ein Fehler auftreten kann dir gleich überlegen mußt wie du damit umgehst sondern einfach eine exception "wirfst" und du dir dann später an einer Stelle für deine 2 oder 3 exceptions passende Fehlerbehandlungen ausdenken kannst.
Generell denke ich aber das es besser ist wenn man "vorhersehbare" Fehler direkt an der entsprechenden Stelle z.B. mit Rückgabewerten verarbeitet und exceptions nur für "unvorhersehbare" Fälle verwendet.

[locus vivendi]

Der Vorposter hatte es schon angedeutet. Exceptions werden verwendet, wenn du an einer Stelle einen Fehler bemerkst, aber nicht weißt wie man an dieser Stelle damit verfahren sollte. Das ist z.B. häufig in Bibliothekscode der Fall. Denn woher sollte der Author einer Bibliothek wissen, was zu tun ist, wenn ein Fehler auftritt? Es könnte ja z.B. die eine Anwendung dann überhaupt nicht mehr sinnvoll arbeiten können, und muss sich deshalb beenden, während eine andere Anwendung den Fehler korrigieren kann.
Deshalb könntest du dir als Richlinie folgendes merken: Alle Fehler, von denen du weiß wie du mit ihnen umgehen kannst, behandelst du an Ort und Stelle. Und für den Rest wirfst du eine Ausnahme.
Bei C++ gibt es aber noch spezifische Überlegungen. Z.b. was ist mit einem Fehler der in einem Konstruktor auftritt? Ein Konstruktor kann ja keinen Wert zurückgeben. Also wird eine Ausnahme werfen wohl das einzige sein, was getan werden kann. Andererseits kann auch ein Destruktor keinen Wert zurückgeben, aber hier darf niemals eine Ausnahme geworfen werden!
Aus diesen Gründen würde ich dir empfehlen, umfangreiche Dokumentation zu diesem Thema zu Rate zu ziehen, es können sich sonst einfach zu viele (subtile) Fehler einschleichen.

[xmarvel]

Erstmal danke für die Antworten. Also try .. catch Methode ist also für unerwartete Programmfehler auftreten.
Aber die Programmfehler die ich schon kenne aufgrund des Benutzer Interaktion z.B. das er beim Laden eine falsche Datei angibt. Die würde ich an Ort und Stelle bearbeiten ?
Was aber doch eigentlich negativ ist denn wenn ich später die Fehlerausgabe auf dem Bildschirm anzeigen will und noch dazu ein error Log erstellen will. Dann müsste ich ja überall den Code abändern.
Also habe ich mir überlegt das ich eine neue Klasse erstelle wo ich eine Methode habe die den Fehler ausgebe. Die Fehlermeldung kann ich ja über ein Parameter mitteilen lassen.
Dann könnte ich im nachhinein ja noch weitere Methoden hinzufügen wie z.B. eben das ich die Fehler noch in eine Log mitprotokolliere.
Was haltet ihr von meiner Idee ? Wär das so Sinnvoll ?

MFG
xmarvel

[locus vivendi]

Also ich weiß jetzt natürlich nicht was für Anforderungen/Bedingungen bei dir noch konkret bestehen. Ich glaube aber das die Art wie der Fehler mitgeteilt wird (Log, Bildschirmausgabe...) orthogonal zu exceptions oder anderer Fehlerbehandlung ist. Du kannst ja die Funktion die du skiziert hast sowohl von einem catch-Block wie auch aus einer normalen Funktion aus ausrufen.
Darf ich dich nochmal auf Literatur verweisen? Ein gutes Buch ist natürlich immer ganz nützlich, aber wenn du keins hast, würde ich dich jetzt ganz konkret auf die "C++ Annotations" verweisen:
http://www.icce.rug.nl/documents/cpp.shtml
Da steht auch was zu exceptions drin. Es finden sich aber auch z.B. ein paar Gedanken dazu auf den Seiten von Boost.

[xmarvel]

Also ich weiß jetzt natürlich nicht was für Anforderungen/Bedingungen bei dir noch konkret bestehen.
Meine Anforderungen wären z.B. das es Wartbar ist und Übersichtlicher Code entsteht.


Ich glaube aber das die Art wie der Fehler mitgeteilt wird (Log, Bildschirmausgabe...) orthogonal zu exceptions oder anderer Fehlerbehandlung ist.
Verstehe denn Satz nicht da ich das Wort orthogonal nicht kenne habe schon gegoogled aber was hat das mit Geometrie zu tuen (http://de.wikipedia.org/wiki/Orthogonal)


Du kannst ja die Funktion die du skiziert hast sowohl von einem catch-Block wie auch aus einer normalen Funktion aus ausrufen.

Ja das ist klar nur catch sollte man ja jetzt nur auf unerwartete Fehlermeldungen benutzen.


Darf ich dich nochmal auf Literatur verweisen? Ein gutes Buch ist natürlich immer ganz nützlich, aber wenn du keins hast, würde ich dich jetzt ganz konkret auf die "C++ Annotations" verweisen:

Klar darfst du. Zwei C++ Bücher habe ich auch aber da wird es eben nur so am Rand beschrieben. Wie ein richtiges Konzept aussieht steht nicht drin.
Der Link funktioniert bei mir irgendwie nicht. Aber bei Boost habe ich den Artikel gefunden werde in mir gleich durchlesen.

MFG
xmarvel

[panzi]

Was ich finde, das ein Vorteil von Exceptions zu Rückgabewert-Errorhandling ist:
Exceptions MÜSSEN gefangen werden (sonst Programmabbruch), Rückgabewerte können auch einfach ignoriert werden (Aufruf als wär der Rückgabewert void).

[locus vivendi]

Der Link sollte funktionieren, habe ich eben nochmal ausprobiert.
Mit Orthogonal meinte ich im wesentlichen das die beiden sachen unabhängig voneinander eingesetzt werden können.