Fehlerbehandlung im Code: damit nichts still abstürzt

Was Fehlerbehandlung ist, einfach erklärt

Stell dir vor, zu Hause platzt ein Rohr. Ab da gibt es zwei Szenarien.

Erstes: irgendwo unter dem Boden tropft leise Wasser. Kein Geräusch, kein Signal. Du lebst einen Monat lang sorglos - und findest dann einen verfaulten Boden und Überschwemmung bei den Nachbarn unten. Der Schaden war da. Und du hast es als Letzter erfahren.

Zweites: das Rohr wird undicht - und sofort kreischt der Sensor, der Hahn schließt sich, aufs Handy kommt eine Benachrichtigung. Unangenehm? Klar. Aber du hast alles in einer Stunde repariert, solange das Problem so groß wie eine Pfütze war.

Genau das ist Fehlerbehandlung. Ein Programm geht immer irgendwo kaputt - das ist so unvermeidlich wie Regen. Die einzige Frage: erfährst du es sofort und menschlich - oder später und als Katastrophe?

Warum Fehlerbehandlung für Vibecoder wichtig ist

Du bist Vibecoder. Den Code schreibt der Agent für dich. Aber genau du entscheidest, wie sich die App verhält, wenn etwas schiefgeht - und das geht ständig schief: das Internet hat geblinzelt, jemand hat Quatsch eingegeben, ein fremder Service hat sich gerade hingelegt.

Gibst du dem Agenten keine Regeln für Fehler, wählt er standardmäßig das Gefährlichste. Er versteckt sie. Von außen läuft alles, und innen tropft es leise.

• Der User sieht einen weißen Bildschirm oder einen ewigen Ladekreis - und geht stillschweigend. Er schreibt dir nicht mal.
• Du verstehst nicht, was kaputtgegangen ist: der Fehler hat nirgends eine Spur hinterlassen.
• Ein winziger Ausfall legt die ganze App lahm - obwohl es eine lokale Kleinigkeit hätte bleiben können.

Der Unterschied zwischen „meine Seite spinnt manchmal, weiß auch nicht warum“ und „ich sehe jedes Problem im Log und repariere es in einer Minute“ - das ist Fehlerbehandlungs-Kultur. Die gute Nachricht: die Regeln sind simpel. Einmal in den Prompt eingebaut - und vergessen.

Fünf Regeln für gute Fehlerbehandlung

Im Skill zur Fehlerbehandlung gibt es fünf eiserne Prinzipien. Schauen wir uns jedes ganz konkret an.

1. Stürz schnell und laut ab

Am schädlichsten ist es, einen Fehler zu schlucken Fehler schlucken (swallow) - einen Ausfall fangen und nichts damit machen: weder anzeigen, noch loggen, noch weiterreichen. Das Programm tut so, als wäre alles in Ordnung, obwohl es das nicht ist. . Geht etwas kaputt - dann muss es genau dort auftauchen, wo es passiert ist. Und nicht tiefer vergraben werden, „um niemanden zu erschrecken“.

Klingt banal. Aber genau hier vergeigen Anfänger (und faule Agenten) es am häufigsten: sie setzen einen Fehler-Catch-Block - und lassen ihn leer. Das ist, als würdest du die blinkende „Check Engine“-Lampe mit Isoband überkleben. Die Lampe blinkt nicht - also alles gut, oder? Klar, klar.

2. Für den Menschen die eine Meldung, für dich eine andere

Auf ein und denselben Fehler braucht es zwei verschiedene Texte:

• Für den Menschen - kurz und höflich: „Etwas ist schiefgelaufen, versuch’s später“. Ohne technische Details, ohne furchteinflößende Wörter, ohne Code-Brocken auf dem Bildschirm.
• Für dich ins Log - die ganze Wahrheit: was genau abgestürzt ist, wo und mit welchen Daten. Das ist dein Leck-Sensor.

3. Ein Fehler braucht einen Namen, nicht nur Text

Ein schlechter Fehler ist eine nackte Zeile "irgendwas ist kaputt". Daraus erkennst du rein gar nichts.

Ein guter Fehler ist typisiert Typisierter Fehler - ein Fehler nicht als zufällige Textzeile, sondern als Objekt mit verständlichem Namen und Code: zum Beispiel NotFound (nicht gefunden), Unauthorized (kein Zugriff), RateLimited (zu oft). Am Code ist sofort klar, was passiert ist und wie man reagiert. : er hat einen Code und einen verständlichen Namen. Schau:

• NotFound - das Angefragte gibt es nicht.
• Unauthorized - man muss sich im Account einloggen.
• ValidationError - der Mensch hat etwas Falsches eingegeben.
• RateLimited - zu viele Anfragen hintereinander, Zeit zum Bremsen.

Wenn Fehler benannt sind, weiß die App genau, was sie dem Menschen zeigt und welche Antwort sie zurückgibt. „Nicht gefunden“ ist eben überhaupt nicht dasselbe wie „kein Zugriff“ oder „unser Server hat sich hingelegt“.

4. Wiederhol die Anfrage mit Köpfchen, nicht mit dem Kopf durch die Wand

Manchmal ist ein Fehler temporär: das Internet hat geblinzelt, der Service hat eine Sekunde gehangen. Hier ist ein Retry mit wachsender Pause Wiederholung mit wachsender Pause (retry with backoff) - wenn eine Anfrage nicht durchging, noch einmal probieren, aber nicht sofort, sondern nach einer Pause, die mit jedem Versuch größer wird. So überlädst du den Server nicht mit einer Schlange identischer Anfragen. angebracht: einmal noch probiert, ging nicht - etwas länger gewartet, und so ein paar Mal.

Aber wiederholen darf man längst nicht alles:

5. Der Fehler ist Teil des Vertrags mit dem, der deinen Code nutzt

Kann die App einen Fehler ‘kein Zugriff’ oder ‘zu viele Anfragen’ zurückgeben - dann soll sie das in einem verständlichen Format jedes Mal tun. Dann wissen das Frontend, du selbst und der zukünftige Agent immer, was sie erwartet. Chaotische, jedes Mal anders aussehende Fehler - das ist die zweite Schmerzquelle gleich nach den stillen.

Beispiel aus dem Leben: das Formular, das stillschweigend Anfragen verlor

Du hast mit dem Agenten ein Kontaktformular auf der Seite gebaut. Durchgeklickt - läuft. Veröffentlicht. Eine Woche später merkst du: null Anfragen. Obwohl der Zähler beteuert, dass das Formular von Dutzenden Leuten geöffnet wurde.

Was wirklich passiert ist:

1. Beim Mail-Versand-Service war das Limit aufgebraucht - er fing an, einen Fehler zurückzugeben.
2. Der Agent hat den Versand standardmäßig in einen Fehler-Catch-Block gewickelt und ihn leer gelassen.
3. Deshalb sah der Mensch ein munteres „Danke, deine Anfrage wurde verschickt!“ - und die Mail flog nirgendwohin. Eine ganze Woche lang hat es leise unter dem Boden getropft.

Wie schützt du dich von Anfang an? Gib dem Agenten einfach die Regeln. Hier ist ein fertiger Prompt:

Wenn du irgendeinen Code schreibst, der kaputtgehen kann (Netzwerk-Anfragen, Arbeit mit der Datenbank, Mail-Versand, User-Eingabe), halte dich an folgende Regeln:


Lass niemals einen leeren Fehler-Behandlungsblock stehen. Jeder solche Block muss den Ausfall entweder korrekt behandeln, ihn weiterreichen oder ins Log schreiben.


Erzeuge zu jedem Fehler zwei Meldungen. Für den User - kurz und höflich, ohne technische Details. Ins Log - die volle Information: was abgestürzt ist, wo und mit welchen Daten.


Zeig dem User keinen Erfolg, solange die Aktion nicht wirklich ausgeführt wurde. Wenn die Mail nicht raus ist - sag ehrlich, dass es nicht geklappt hat, und biete an, es zu wiederholen.


Verwende verständliche Fehlertypen mit Code: nicht gefunden, kein Zugriff, ungültige Eingabe, zu viele Anfragen, interner Fehler.


Wiederhole eine Anfrage nur automatisch, wenn sie zufällig abstürzen konnte (Netz, Timeout). Mach den Retry mit wachsender Pause und begrenze die Zahl der Versuche auf drei. Eingabe- und Zugriffsfehler nicht wiederholen.

Zeig mir am Ende eine Liste der Stellen, an denen der Code abstürzen kann, und wie du in jeder davon den Fehler behandelst.

Gesunde und kranke Fehlerbehandlung: ein Vergleich

Checkliste: Schweigt deine App über Fehler?

Bevor du etwas an Menschen ausrollst, geh die Checkliste durch:

1. Was sieht der Mensch, wenn das hier kaputtgeht? Die Antwort „weißer Bildschirm“ oder „weiß nicht“ ist schlecht.
2. Wo sehe ich, dass das kaputtgegangen ist? Wenn nirgends - füg ein Log hinzu.
3. Gibt es leere Fehler-Behandlungsblöcke? Bitte den Agenten, alle Stellen mit Fehler-Catch zu zeigen und was dort passiert.
4. Zeige ich Erfolg zu früh an? „Verschickt“ darf erst nach dem echten Versand erscheinen.
5. Sind Secrets in die Logs abgeflossen? Passwörter, Tokens und Keys haben in Logs nichts zu suchen.

Häufige Anfängerfehler bei der Fehlerbehandlung

• Den Fehler-Catch-Block leer lassen. Die gefährlichste Angewohnheit der Welt. Der Fehler verschwindet, das Problem wächst im Dunkeln.
• Dem Menschen technischen Text zeigen. Ein Stacktrace auf dem Bildschirm erschreckt normale Leute und hilft Angreifern. Ihnen eine höfliche Meldung, dir das Log.
• Über Erfolg lügen. „Fertig!“ bevor die Aktion wirklich passiert ist - der direkte Weg zu verlorenen Anfragen und Bestellungen.
• Wiederholen, was sich per Retry nicht reparieren lässt. Ein falsches Passwort oder „nicht gefunden“ hundert Mal hintereinander - reine Kraftverschwendung und Last für den Server.
• Endlose Retries ohne Limit. Du zerlegst den fremden Service, und nebenbei hängt sich auch deine eigene App auf.
• Secrets loggen. Verlockend, „die ganze Anfrage komplett“ aufzuschreiben, aber da landen oft Passwörter und Keys. Wisch das Sensible raus.