Artur Södler Software-Qualität

Fehlerbehandlung

Die Fehlerbehandlung ist das A und O jeder Anwendung. Natürlich geht immer mal etwas schief. Und genauso selbstverständlich ist, dass sich der Softwareentwickler gar nicht vorstellen kann, was alles schiefgeht. Das liegt in der Natur der Sache:

Der Softwareentwickler hat den Auftrag, dafür zu sorgen, dass bestimmte Anforderungen erfüllt werden. Folglich denkt er nicht daran, was alles schiefgehen kann, sondern nur daran, wie alles funktioniert.

Wir müssen umdenken: Der Softwareentwickler hat auch den Auftrag, dafür zu sorgen, dass in allen anderen Fällen kein Schaden entsteht. Das heißt auch, dass wir die über die Ursachen etwaiger Probleme genau informiert werden, um sie abstellen zu können.

Ein Beispiel: Beim Beenden des FiBu-Programmes fragt das Programm nach, ob die geänderten Buchhaltungsdaten gespeichert werden sollen. Wir drücken den Knopf "Ja". Die Datei existiert bereits auf der Festplatte, aber in einem älteren Zustand. Mitten während des Speicherns stellt das System fest, dass nicht genug Platz auf der Festplatte ist, das Speichern bricht ab.

Schlechtestenfalls sind die FiBu-Daten nun auf der Festplatte korrupt, die Software sagt gerade noch, dass das Speichern fehlschlug, und beendet sich trotzdem.

Bestenfalls wurde erst einmal unter einem anderen Namen gespeichert. Erst wenn die neue Datei Platz genug hatte, wird die alte gelöscht, und die neue umbenannt. Bevor also die Fehlermeldung erscheint, versucht die Software erst noch, die angebrochene Datei wieder zu löschen. Anschließend sagt sie, 1. dass der Datenträger voll ist, 2. dass dadurch das Speichern von "n:\Verwaltung\FiBu\2014.db" fehlschlug, und 3. dass deshalb das Programm nicht geschlossen wird.

Fehlerbehandlung ist nicht einfach. Hier ein paar Grundsätze:

•		Alles kann schiefgehen. Auch der Speicher zum Verarbeiten einer Fehlermeldung kann ausgehen, für ein Meldungsfenster stehen nicht genug Ressourcen zur Verfügung, der erfolgreich gesendete Ausdruck wird im Drucker zu Ziehharmonika-Papier verarbeitet. Der Fortschrittsbalken stürzt ab, wenn eine leere Datenmenge verarbeitet wird.
•		Fehler haben Ursachen und Wirkungen in Form einer Kette. Die Elemente sind oft zugleich Wirkung des vorigen und Ursache der nächsten Elements. Wirkungen sind gleichzusetzen mit Kontext: Scheitert das Speichern einer Konfiguationsdatei mit der letzten Bearbeitungsposition im Text, dann ist das grundsätzlich anders zu bewerten, als wenn der bearbeitete Text selbst nicht gespeichert werden kann. Studienbeispiel: die Java-Klasse Throwable.
•		Fehler sind nicht immer Fehler. Der Datensatz wurde nicht gefunden? Dann legen wir einen an. Kein Grund, den Anwender mit einer Fehlermeldung zu belästigen.
•		Bestimmte Fehler müssen identifizierbar sein. Der Fehler "keine weiteren Daten vorhanden" (siehe Beispiel im letzten Punkt) muss als Kode identifizierbar sein, nicht als Text. Rechnen Sie damit, dass die Datenbank überraschenderweise "No hay más expedientes." sagt.
•		Nicht identifizierte Fehler können nicht ignoriert werden. Nur zwei Ausnahmen gibt es: a) Die Sache wurde auf andere Weise zum sicheren Erfolg gebracht. b) Es gibt weitere Fehlermeldungen, die wichtiger oder ursächlicher sind.
•		Fehlerinformationen müssen speicherbar sein. Der Server ist nicht ansprechbar? Kein Problem, versuchen wir es mit dem Backup-Server. Wenn der aber auch nicht funktioniert, stellen wir doch besser die Original-Fehlermeldung dar.
•		Unterprogramme hinterlassen im Fehlerfall keine Nebenwirkungen. Die halb geschriebene Datei wird wieder gelöscht. Die Neuanlage hinterlässt keine leeren Datensätze. Der Import importiert keine halbe Datenmenge. Diese Forderung ist nicht immer umsetzbar. Aber sie erleichtert vieles. Der Anwender muss vor dem nächsten Versuch nicht erst aufräumen.
•		Nichts schlägt endgültig fehl, und schon gar nicht nach einer bestimmten Zeit. Der Windows-Hardware-Explorer "wartet" eine festgelegte Zeit auf Antworten der angeschlossenen Hardware. Die Hardware, die sich nicht rechtzeitig meldet, wird ignoriert. Denken Sie um: Notwendige Voraussetzungen sind noch nicht erfüllt — bis sie erfüllt sind. Eine festgelegte Anzahl Wiederholungen oder eine Höchst-Dauer kann immer nur als Umsetzung der Erfahrung eines Menschen gerechtfertigt sein.
•		Das Entstehen einer Fehlerinformation ist am besten von einer Exception begleitet. Auf diese Weise kommt man weniger in Versuchung, ungültige Daten aus Versehen weiterzuverarbeiten mit Folgen wie "Division durch Null". Entweder wird ein Throwable (Java) oder vergleichbares geworfen, oder in einem globalen Objekt hinterlegt, und ein dummy-Wert geworfen. Die Standardmechanismen aller Programmiersprachen sind unvollständig, aber nachrüstbar.