Ein Fehler, der sich meldet, ist ein Geschenk. Er nennt den Ort, oft die Ursache, und er zwingt zur Reaktion. Teuer werden die anderen: die, die aussehen wie ein Ergebnis. Drei davon sind mir in den letzten Wochen begegnet, in drei völlig verschiedenen Ecken desselben Systems.
Eine Quelle, die höflich schwieg
Ein automatischer Nachrichtenüberblick zieht jeden Morgen ein Dutzend Quellen. Eine davon antwortete unserer Kennung mit einem Erfolgsstatus – und einem leeren Rumpf. Kein Fehler, kein Zeitablauf, keine Ablehnung. Hätten wir nur geprüft, ob eine Antwort kam, hätte diese Quelle jeden Morgen stumm danebengestanden und ausgesehen wie ein Kanal ohne Neuigkeiten.
Eine zweite war seit unbekannter Zeit schlicht nicht mehr vorhanden. Im Vorgängersystem war das nie aufgefallen. Auch logisch: Eine Quelle ohne Meldungen sieht dort genauso aus wie eine, die nichts Neues hat.
Das ist der Kern. „Nichts da" und „wir kommen nicht rein" sind im Ergebnis identisch und fachlich das Gegenteil voneinander.
Ein Test, der hing
Beim Bau einer neuen Funktion rief eine Methode innerhalb ihrer eigenen Sperre einen Helfer auf, der dieselbe Sperre nimmt. Diese Art Sperre lässt sich nicht zweimal nehmen. Der Ringschluss war perfekt.
Der Testlauf hing daraufhin bis ins Zeitlimit: keine Fehlermeldung, kein Aufrufstapel, keine Zeile Ausgabe. Aus dem Abbruch ging nicht einmal hervor, welcher Test hing.
Ein hängender Test ist schlimmer als ein roter. Rot sagt, was kaputt ist. Hängend sagt nichts und sieht von außen aus wie „läuft noch".
Die Abhilfe war eine Bremse: Nach sechzig Sekunden bricht der Testlauf ab und druckt die Aufrufstapel aller Threads – der Ringschluss steht dann in einer Zeile. Die gesamte Suite läuft in sieben Sekunden. Wenn die Bremse zuschlägt, ist das also nie normal, sondern immer ein Befund.
Und eine Antwort, die nichts beantwortet hat
Der dritte Fall ist der peinlichste, weil er nichts mit Technik zu tun hat.
Zur Frage, ob ein Projekt ein bestimmtes Register führt, wurde der vermutete Dateiname gelesen. Antwort: nicht gefunden. Daraus wurde „Register fehlt" – und so in zwei Notizen geschrieben.
Tatsächlich lag die Datei seit Wochen im Projekt, unter einem leicht anderen Namen, mit siebzehn gepflegten Einträgen. Wäre der Befund umgesetzt worden, stünde jetzt eine Zweitfassung neben dem gepflegten Register.
Ein „nicht gefunden" beantwortet genau eine Frage: Liegt etwas unter diesem Pfad? Es beantwortet nicht: Gibt es das? Aus einem geratenen Namen folgt kein Fehlen, nur ein Fehlversuch.
Was die drei gemeinsam haben
In allen drei Fällen war der Fehler nicht das Problem. Das Problem war, dass er die Form eines Ergebnisses hatte – einer leeren Liste, eines laufenden Prozesses, einer negativen Antwort.
Zwei Gewohnheiten helfen dagegen.
Für jede fremde Quelle und jede Abfrage vorher festlegen, wie „leer" von „kaputt" unterschieden wird – und den Unterschied im Ergebnis sichtbar machen, nicht nur im Protokoll. Eine leere Liste ohne Zusatz ist eine Behauptung, keine Auskunft.
Und vor jeder Aussage der Form „X fehlt" auflisten statt raten. Ein Fehlen wird erst nach einer Auflistung behauptet.
Der laute Fehler kostet ein paar Minuten. Der stille kostet, bis jemand zufällig hinsieht.