• 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 Tests für jeden Fehler, den du findest.

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

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