Modernes Ausnahmesystem

EOutOfResources

Hallo

Wie sieht ein heutiges modernes C++-Ausnahmesystem aus? Wenn ich das schon falsch mache, ist die ganze Lib wieder für'n Arsch.

MfG, EOutOfResources

PS: In der alten Lib habe ich das von C++ angebotene System verwendet. Es soll ja ab C++0x deprecatet sein.

theta

AFAIK ändert da der neue Standard nur die Exception Specifications.

DrGreenthumb

in C++0x hat sich afaik nur die Exceptionspezifikation bei Funktionen geändert.

Ich verwende boost::exception. Dabei vor allem wegen der Eigenschaft, dass die Exception-Attribute nicht in der Exception selbst definiert sind, sondern extra.

Also statt

struct Error {string name;};
throw Error ("abc");

sieht das dann so (ähnlich) aus:

struct Error {};
typedef boost::error_info<string> name;
throw Error() << name ("abc");

Ob das bei boost so praktisch umgesetzt ist, ist eine andere Frage. Habe auch schon mit dem Gedanken gespielt, lieber throw Error().set ("name", "abc"); zu nehmen.

*rant*

theta schrieb:

AFAIK ändert da der neue Standard nur die Exception Specifications.

Exception specifications sind gelinde gesagt Schrott in C++. Der einzige Fall, wo sie vielleicht brauchbar sind, ist wohl nothrow. Ansonsten würde ich eher die Finger davon lassen.

theta

@rant: Ganz meine Meinung. Ich habe auch nichts anderes behauptet.

Nexus

Exception Specifications würde ich nie verwenden, auch kein throw() . Dafür gibts ab C++0x noexcept .

Wichtig ist meiner Meinung nach auch, nicht für alle möglichen Fehler Exceptions einzusetzen. Gerade bei Logikfehlern, die in korrekt geschriebenen Programmen nicht auftreten, wäre ich sehr zurückhaltend. Lieber assert einbauen und Exceptions für Laufzeitfehler aufsparen. Und halt prüfen, ob es semantisch gesehen Sinn macht, von einer Ausnahme zu sprechen – bei einem Search() ist das z.B. nicht der Fall.

Eine Exception-Hierarchie ist natürlich nicht schlecht. Wie die genau aussieht, hängt davon ab, welche Ausnahmen in deinem Programm vorkommen können.

Exception-Sicherheit ist ebenfalls ein sehr wichtiges Thema. Wenn du Idiome wie RAII und Copy-and-Swap einsetzt, musst du dafür nicht mal viel tun.

Ich denke wesentlich ist hier, wann, wo welche exception geworfen und gefangen werden sollen. Hier geht es weniger um die Hierarchie der Exception-Typen, als mehr um das Design einer Komponente.

Ich verwende oft das Design, dass eine Komponente (nicht Klasse) an ihren Schnittstellen die Zusicherungen prüft, ggf. eine Exception erzeugt und im Fehlerbehandlungsteil, der vom Rest der Komponente so weit wie es geht getrennt ist, die Fehler gemäß Spezifikation behandelt (Loggin, Restart, ...).

Das führt dazu, dass der eigentliche Code nicht mit Fehlerbehandlung "durchwachsen" ist.