Seit der ersten Standardisierung von C++ im Jahr 1989 gibt es mit Exceptions oder zu Deutsch 'Ausnahmen' eine neue Möglichkeit in C++ Fehler zu behandeln. Sie realisieren dabei das Prinzip der Strukturierten Fehlerbehandlung, also der Trennung des normalen Programmablaufs von der Fehlerbehandlung. Eine zentrale Rolle spielt dabei der Begriff der Exception, also ein Objekt das beim Auftreten eines Fehlers erzeugt wird, und alle Informationen über den aufgetreten Fehler beinhaltet. Da Aufgrund fehlender Informationen Fehler oft nicht direkt an der Stelle ihres Auftretens behandelt werden können werden die Exceptions an eine spezielle Fehlerbehandlungsroutine übergeben die ausreichend Kontextinformationen besitzt um den Fehler zu behandeln.

Um zu bestimmen welche Fehlerbehandlungsroutine die Richtige ist bedient man sich der sogenannten Blocküberwachung. Dabei kennzeichnet man gewisse Blöcke des Programms, welche auf ineinander verschachtelt sein können, das in ihnen Fehler auftreten können und schreibt im Anschluss an jeden Block, ein oder mehrere Fehlerbehandlungsroutinen für verschiedene Arten von Fehlern. Sollte ein Block einen Fehler nicht bearbeiten können wird er an den umgebenden Block weitergegeben, solange bis entweder ein Block den Fehler behandeln kann oder bis kein umgebender Block mehr vorhanden ist, wobei dann das Programm beendet wird.

Das Weiterreichen von Fehlern funktioniert auch über die Grenzen von Funktionen hinweg, so dass Funktionen die mit dem Fehler nichts anfangen können frei von Code zum Behandeln bzw. Weiterreichen dieses Fehlers bleiben.

• Verwendung und Syntax
• Was passiert wenn eine Exception auftritt? ⇒ Scott Meyers

• Unbehandelte Exceptions
• Exceptions in Exceptions
• Exceptions im Konstruktor - Über Fehler im Konstruktor benachrichtigen
• Ausnahmegarantien → C++0x noexcept(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3051.html)
• Exceptionsicheres Design → zb. copy/assignment mit swap etc. (basic/strong Garantie, nothrow)
• Standard Exceptions
• Möglichkeiten: RAII, Scopguards (Mutexes), etc.
• Chaining - Weiterleiten und Anreichern mit Informationen → ev. auch http://www.boost.org/doc/libs/1_42_0/libs/exception/doc/boost-exception.html
• Änderungen in C++0x getrennt?
• unexpected() ⇒ Programmdaten retten
• exception::what()?

• Leaks mit rohen Zeigern → Smartpointer
• Binäre (In-)kompatibilität (ABI)
• catch muss prüfen, was existiert und ggfs. freigeben? (Stackunwinding mit Pointern, SmartPointer ⇒ Speicherverbrauch?) / Mehrere new können std::alloc werfen. Ob was zu retten ist, muss erst herausgefunden werden
• Wer hat eine Exception warum ausgelöst? Verleitet zum Weiterleiten.
• throws garantiert nichts (C++0x depreciated)
• Polymorphie bei Exceptions ⇒ Basisklasse fängt unbekannte abgeleitete Klasse ⇒ unwartbar
• Exception-Ping-Pong
• catch(…) http://stackoverflow.com/questions/2474429/does-throw-inside-a-catch-ellipsis-rethrow-the-original-error
• Exceptions in Destruktoren

• Exceptions sind TEAM-Work : Toll ein anderer machts
• Referenzen statt NullPointerExceptions
• „Ich bin auch nicht der Meinung, dass man alle Fehler mit Exceptions behandeln sollte. Ich verwende das abhängig von der Situation. Wenn ich zum Beispiel einen (Smart)Pointer zurückgebe, kann ich auch einfach Null bzw. einen leeren Smartpointer zurückgeben.“
• bool b = obj.GetInformation( Data /*reference*/ );
• Data = obj.GetInformation( defaultValue );
• new(std::nothrow)

• Fehlercode
• defaultwert
• bool b = obj.GetInformation( Data /*reference*/ );
• Data = obj.GetInformation( defaultValue );
• Exceptions
• Kostenbetrachtung
• ignorieren?

http://www.vollmann.ch/en/pubs/cpp-excpt-alt.html
http://www.boost.org/community/error_handling.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3051.html
http://www-personal.acfr.usyd.edu.au/tbailey/seminars/exceptions.pdf