# Fehlerbehandlung Eine hochwertige Software sollte niemals unerwartetes Verhalten aufweisen. Daher ist es wichtig, auch mit Fehlern zu rechnen. Möchte man also unerwartetes Verhalten möglichst vermeiden, muss man auf diese Fehler reagieren. Dazu nutzt man sogenanntes Fehlerhandling (Exception Handling). ## Mit Fehlerhandling beginnen Folgt man der TDD-Vorgehensweise, werden zuerst die Testfälle geschrieben. Anschliessend sollte das erwartete Verhalten eingebaut werden, um nach und nach alle Features einzubinden. Diese Tests sollten möglichst viele Fälle abdecken, was auch die Prüfung von Fehlern umfasst. Möchte man also das erwartete Verhalten für diese einbauen, ist es naheliegend, mit der Fehlerbehandlung anzufangen. Dies kommt mit vielen Vorteilen: - Unerwartetes Verhalten kann schneller identifiziert werden, da die erwarteten Fehler bereits behandelt werden. - Die Fehlerbehandlung skaliert einfacher mit neuen Features. - Neue Tests können einfacher geschrieben werden, da sich keine Sorgen mehr um Fehler gemacht werden müssen. ## Informative Fehler werfen Die standardmässig mitgelieferten Exceptions sind bereits hilfreich. Es wird jedoch sehr schnell schwierig, die Fehlermeldungen auseinanderzuhalten, wenn nur allgemeine Fehler behandelt werden. Dies kann es stark erschweren, den Ursprung eines Fehlers zu finden. Es wird standardmässig ein Stacktrace mitgegeben, der bereits Aufschluss bieten kann. Aber auch dieser ist nicht immer eindeutig. Stattdessen sollte immer zumindest eine eigene Nachricht mitgegeben werden, die die Herkunft des Fehlers aufzeigt. Ein noch besserer Weg wäre jedoch das Schreiben einer eigenen Exception. ## Eigene Fehler werfen Es gibt allerlei Szenarien, für die es keine bereitgestellte Exception gibt. Natürlich könnte man einfach eine oberflächliche Exception werfen (wie die Exception-Klasse selbst), es ist jedoch viel schöner, wenn dafür eine eigene Exception geschrieben wird. ## Nie Null zurückgeben Es sollte allgemein nie ein Null-Objekt zurückgegeben werden. Der Grund dafür sollte auch offensichtlich sein: Es verlangt nach ständiger Überprüfung auf Null und Handhabung, falls dies der Fall ist. Wenn eine Überprüfung vergessen wird, kann das zu unzähligen NullPointerExceptions führen, die schwierig zu lokalisieren sind. Hat man jetzt aber einen Fall, bei dem es nötig ist, dass kein Objekt zurückgegeben wird, dann sollte stattdessen eine eigene Exception geworfen werden, die in einem höheren Layer einfach behandelt werden kann.