====== Fehlerbehandlung ======
  * Lasse niemals einen Fehler unter den Tisch fallen (sondern propagiere ihn zum Aufrufer, wenn du ihn nicht behandeln kannst).
    * Fehler zu ignorieren spart keine Zeit ein, da man später umso mehr Zeit für das Debuggen braucht.
  * Überprüfe jeden Rückgabewert von Funktionen.
  * Behandle Fehler so früh wie möglich (-> je dichter am Auftreten umso klarer die Behandlung und somit der Code)
  * Schreibe [[unittests|Tests]] für jeden Fehler, den du findest.

===== Exception Safety =====
**nach \cite[S. 94]{Goodliffe2006}**
  * Code muss laufen, egal, welche Exceptions auftreten
  * **Exception-neutraler** Code wirft alle Exceptions weiter an den Aufrufer
  * Exception-Garantien
    * basic: beim Auftreten einer Exception werden keine Ressourcen ungültig und das Programm bleibt konsistent (wenn auch vielleicht nicht in einem definierten Zustand)
    * strong: beim Auftreten einer Exception bleibt der Zustand des Programms völlig unberührt davon (keine Variablen werden verändert etc.)
    * nothrow: eine Funktion kann niemals eine Exception werfen
  * je höher die Exception-Garantie eines Programms umso höher ist sein Wiederverwendungswert

===== Fehlermeldungen =====
**nach \cite[S. 101]{Goodliffe2006}**
  * Fehlermeldungen müssen die Sprache der Benutzer sprechen (nicht die der Entwickler)
  * keine kryptischen Ausdrücke verwenden
  * keine Fehlercodes ausgeben, mit denen der Anwender nichts anfangen kann
  * Warnings und Error unterscheiden
  * Stelle nur Fragen an den Benutzer (z.B. Fortfahren ja/nein), wenn er auch sicher die Konsequenzen versteht