Fehlerbehandlung in der Softwareentwicklung: So schreiben Sie für die Zukunft

Fehlerbehandlungen in der Softwareentwicklung folgen häufig einem gefährlichen Muster: Sie werden für den Moment geschrieben, nicht für die Zukunft. Ein Entwickler sieht die Fehlermeldung direkt am Terminal, erinnert sich sofort an den letzten Befehl und korrigiert das Problem innerhalb von Sekunden. Doch diese Fehlermeldungen sind selten für diejenigen gedacht, die sie wirklich benötigen – die Kollegen, die Monate später mit demselben Fehler konfrontiert werden und keine Ahnung haben, was damals passiert ist.

Warum Fehlermeldungen oft ins Leere laufen

Die meisten Fehlermeldungen sind als kurze Hinweise konzipiert. Sie enthalten Begriffe wie Verbindung abgelehnt oder Validierung fehlgeschlagen in Schritt 3. Für den Entwickler, der den Fehler gerade sieht, reicht diese Information aus, weil er den gesamten Kontext im Kopf hat: Was wurde zuletzt geändert? Welche Systeme waren beteiligt? Welche Daten wurden verarbeitet? Die Meldung dient nur als Erinnerung.

Doch in asynchronen Systemen sieht die Realität anders aus. Ein Agent führt um 2 Uhr nachts eine Pipeline aus, ein Schritt scheitert – doch niemand bemerkt es sofort. Erst Stunden oder Wochen später beginnt ein Kollege mit der Untersuchung. Dieser Kollege hat keine Erinnerung an das System, keinen Zugriff auf frühere Logs und keine Konversation, auf die er sich beziehen kann. Für ihn ist die Fehlermeldung die einzige Informationsquelle. Wenn sie nicht ausreichend Details enthält, ist der Fall praktisch unlösbar.

Fehlerberichte als Aufzeichnungen, nicht als Nachrichten

Die zentrale Erkenntnis: Die meisten Fehlermeldungen sind Nachrichten – sie setzen gemeinsamen Kontext voraus. Doch was asynchrone Systeme brauchen, sind Aufzeichnungen. Eine Nachricht wie Validierung fehlgeschlagen ist ausreichend, wenn der Leser den Kontext teilt. Eine Aufzeichnung hingegen muss alles enthalten, was ein Unbeteiligter wissen muss, um den Fehler zu verstehen und zu beheben.

Die entscheidende Frage lautet: Könnte ein Kollege, der nur die Fehlermeldung sieht und keine weiteren Systeminformationen hat, den Fehler rekonstruieren? Wenn die Antwort „nein“ lautet, handelt es sich um eine Nachricht, die als Aufzeichnung getarnt wurde.

Um das zu vermeiden, sollten Fehlermeldungen folgende Elemente enthalten:

• - Was war die Eingabe? Welche Daten wurden verarbeitet?
• - Welcher Schritt ist fehlgeschlagen? Nicht nur die Nummer, sondern die genaue Beschreibung der Aufgabe.
• - Welche Erwartungen wurden nicht erfüllt? Was sollte passieren, was ist stattdessen geschehen?
• - Welche Wiederholungsversuche gab es? Wurde der Schritt erneut ausgeführt? Mit welchem Ergebnis?

Diese Informationen mögen auf den ersten Blick redundant wirken. Doch sie sind der Unterschied zwischen einem lösbaren und einem unlösbaren Fall.

Der unsichtbare Leser: Warum Systeme für Fremde entworfen werden müssen

Ein weiterer kritischer Faktor ist der Zeitablauf. Der ursprüngliche Entwickler eines Systems hat oft bereits das Unternehmen verlassen, ist in eine andere Abteilung gewechselt oder hat sich einem neuen Projekt zugewandt. Der Kollege, der den Fehler drei Monate später untersucht, ist ein Fremder – jemand, der nie an der ursprünglichen Entwicklung beteiligt war.

Diese Situation stellt die höchste Anforderung an die Qualität einer Fehlermeldung. Sie muss nicht nur technisch korrekt sein, sondern auch für jemanden verständlich, der das System zum ersten Mal sieht. Eine Fehlermeldung, die nur für Entwickler mit Vorwissen funktioniert, ist wertlos.

Praktische Veränderungen in der Fehlerbehandlung

Die Umstellung auf eine zukunftssichere Fehlerbehandlung erfordert keine revolutionären Maßnahmen. Einige einfache Änderungen reichen aus:

• - Kontext in jeder Meldung: Statt Schritt 3 fehlgeschlagen sollte stehen: Schritt 3 (Datenvalidierung) ist mit den Eingabedaten [X] fehlgeschlagen, da die erwarteten Felder [Y] nicht vorhanden waren.
• - Fehlermeldungen als Audit-Trail behandeln: In asynchronen Systemen gibt es keine anderen Protokolle. Die Fehlermeldung ist die einzige Aufzeichnung. Sie sollte daher von Anfang an so gestaltet sein, als wäre sie die einzige Informationsquelle.
• - Fehlerbehandlung nicht für Demo-Zwecke optimieren: Eine Fehlermeldung, die im Live-System gut aussieht, ist nicht zwangsläufig hilfreich, wenn sie im Hintergrund auftritt. Die Anforderungen sind unterschiedlich.

Diese Anpassungen erfordern kaum zusätzlichen Aufwand, können aber Stunden oder Tage an Debugging-Zeit sparen. Sie verwandeln eine einfache Fehlermeldung in eine wertvolle Ressource.

Der kleinste gemeinsame Nenner: Schreiben Sie für den Fremden

Die zentrale Botschaft lässt sich in einem Satz zusammenfassen: Nützlichkeit im Moment und Nützlichkeit in drei Monaten sind zwei verschiedene Anforderungen. Und Sie können meist nur eine davon erfüllen. Die Entscheidung fällt leicht, wenn Sie sich vor Augen führen, wer die Fehlermeldung wirklich braucht.

Schreiben Sie nicht für sich selbst. Schreiben Sie nicht für den Kollegen, der gerade neben Ihnen sitzt. Schreiben Sie für den Fremden – die Person, die in Zukunft mit Ihrem System arbeiten wird und keine Ahnung hat, was damals passiert ist. Denn genau diese Person wird die Fehlermeldung lesen, wenn Sie längst nicht mehr da sind, um sie zu erklären. Und an diesem Punkt entscheidet die Qualität Ihrer Aufzeichnung, ob der Fehler behoben wird oder für immer im Dunkeln bleibt.