Fehlerbehandlungs-Review

Das Problem

Fehlerbehandlung ist die am meisten vernachlaessigte Dimension der Codequalitaet. Entwickler wrappen alles in try/catch und loggen in die Konsole — Fehler werden stillschweigend verschluckt, die laut crashen sollten. Netzwerkanfragen setzen Erfolg voraus. Formularuebermittlungen zeigen nichts, wenn die API 500 zurueckgibt. Das Ergebnis: Nutzer sehen leere Bildschirme, Daten werden still korrumpiert, und Debugging wird zur archaeologischen Spurensuche.

Der Prompt

Pruefe die Fehlerbehandlung im folgenden Code. Handle als Reliability Engineer, der das Systemverhalten bei Fehlern bewertet.

SPRACHE/FRAMEWORK: [z.B. TypeScript/React, Python/FastAPI, Go]
KONTEXT: [z.B. Zahlungsverarbeitung, Nutzerregistrierung, Datei-Upload]

CODE:
[Code hier einfuegen]

Bewerte diese Fehlerbehandlungs-Dimensionen:

1. **Catch-Qualitaet**
   - Sind Catch-Bloecke zu breit (Error statt spezifischer Typen)?
   - Verschlucken Catch-Bloecke Fehler still (leerer Catch, nur console.log)?
   - Werden Fehler re-thrown, wenn sie aufsteigen sollten?
   - Wird der Originalfehler in gewrappten Exceptions erhalten (Cause Chaining)?

2. **Nutzerkommunikation**
   - Sieht der Nutzer eine hilfreiche Meldung, wenn etwas fehlschlaegt?
   - Sind Fehlerzustaende gestaltet, oder wird die UI einfach leer?
   - Werden transiente Fehler (Netzwerk, Timeout) von permanenten unterschieden?
   - Gibt es einen Retry-Mechanismus fuer behebbare Fehler?

3. **Grenzschutz**
   - Werden API-Responses vor Nutzung validiert?
   - Haben Datenbankoperationen Transaction-Rollback bei Fehler?
   - Sind Dateioperationen mit Cleanup in finally-Bloecken gewrappt?
   - Haben externe Service-Aufrufe Timeouts konfiguriert?

4. **Fehlerweiterleitung**
   - Ist die Fehlerweiterleitung konsistent (throw vs. Result vs. Callback)?
   - Kann der Aufrufer zwischen Fehlertypen unterscheiden?
   - Werden async Fehler behandelt (unhandled Promise Rejections)?

5. **Beobachtbarkeit**
   - Werden Fehler mit genuegend Kontext geloggt (User-ID, Request-ID, Eingabedaten)?
   - Werden Fehlerraten ueberwacht (nicht nur geloggt)?

Fuer jedes Problem liefere:
- **Ort**: Datei und Zeile
- **Fehlermodus**: Was in Produktion passiert
- **Schweregrad**: Stiller-Fehler / Schlechte-UX / Daten-Risiko / Crash
- **Fix**: Verbesserter Fehlerbehandlungscode

Beispielausgabe

## Fehlerbehandlungs-Review: 5 Probleme gefunden

### Stiller Fehler: Verschluckter Datenbankfehler
Ort: src/services/user.ts:34
Code:
  try { await db.insert(user); }
  catch (e) { console.log('insert fehlgeschlagen'); }
Fehlermodus: Nutzer sieht Erfolgsmeldung, aber Daten wurden nie gespeichert.
Fix:
  try { await db.insert(user); }
  catch (error) {
    logger.error('User-Insert fehlgeschlagen', { userId: user.id, error });
    throw new DatabaseError('Nutzer konnte nicht erstellt werden', { cause: error });
  }

Wann verwenden

Bei Code ausfuehren, der Nutzereingaben, Netzwerkanfragen, Datenbankoperationen oder Zahlungen verarbeitet. Unverzichtbar vor Produktions-Deployments und nach Vorfaellen, bei denen “der Fehler wurde gefangen, aber niemand hat es bemerkt” die Ursache war.

Profi-Tipps

• Unhappy Path testen — nach dem Review fragen: “Generiere Testfaelle, die jeden Fehlerpfad in diesem Code ausueben.”
• Fehlertaxonomie anfordern — “Kategorisiere alle moeglichen Fehler in behebbar (Retry), nutzerbehebbar (Formularfehler) und fatal (Fehlerseite).”
• Error Boundaries pruefen — in React-Apps fragen: “Wo sollten Error Boundaries platziert werden, um einen App-weiten Crash zu verhindern?”