Fehlerbehandlung bei Promises und async/await

Ziel

Jedes abgelehnte Promise wird entweder dort behandelt, wo sich sinnvoll etwas tun lässt, oder als protokollierter Fehler mit Kontext sichtbar gemacht. Keines wird stillschweigend verworfen, und keines bringt den Prozess überraschend zum Absturz.

Voraussetzungen

Eine async-Funktion gibt immer ein Promise zurück: Ein throw darin wird zu einer Ablehnung, und await auf ein abgelehntes Promise wirft an dieser Stelle erneut (MDN). Die Richtlinie der Laufzeitumgebung für Ablehnungen kennen, die niemand behandelt: Browser lösen ein unhandledrejection-Ereignis auf window aus; Node.js löst es bei der Standardeinstellung --unhandled-rejections=throw als nicht abgefangene Ausnahme aus, die den Prozess beendet, sofern sie nicht behandelt wird.

Schritte

1. Für jeden erwarteten (awaited) Aufruf entscheiden, ob sich der Aufrufer erholen kann (erneut versuchen, ausweichen, eine Meldung anzeigen). Erst dann abfangen: try { data = await load(); } catch (e) { ... } um die Anweisungen legen, die scheitern können, nicht um die ganze Funktion.
2. Wenn keine Erholung möglich ist, die Ablehnung weiterreichen oder einen spezifischeren Fehler erneut werfen, der das Original anhängt (new Error("profile load failed", { cause: e })), damit der Stack erhalten bleibt.
3. Nie ein Promise unbehandelt schweben lassen. Ein Aufruf ohne await, return oder .catch ist eine Ablehnung, die niemandem gehört; eine Lint-Regel aktivieren, die nicht awaitete Promises markiert, und jeden Treffer beheben.
4. .then()-Ketten und await nicht in derselben Funktion mischen; ein fehlendes return innerhalb von .then verbirgt den Fehler vor dem umschliessenden try.
5. Bei nebenläufiger Arbeit bewusst wählen: Promise.all, wenn ein Fehlschlag den ganzen Stapel ungültig macht, Promise.allSettled, wenn Teilergebnisse nützlich sind. So oder so erhält jedes eingehende Promise einen Handler, sodass spätere Fehlschläge nicht unbehandelt bleiben.
6. Einen letzten Handler registrieren, der den Grund und den Ursprung des Promise protokolliert: window.addEventListener("unhandledrejection", ...) im Browser, process.on("unhandledRejection", ...) in Node.js. In einem Serverprozess protokollieren und beenden, statt mit unbekanntem Zustand weiterzulaufen.
7. Immer mit Error-Instanzen ablehnen; ein abgelehnter String hat weder Stacktrace noch cause.
8. Für jeden dokumentierten Fehlerpfad einen Test schreiben, der Typ und Meldung der Ablehnung prüft.

Erwartetes Ergebnis

Fehler erscheinen einmal, in einer Log-Zeile mit Kontext, auf der Ebene, die entschieden hat, was damit geschieht. CI-Läufe zeigen keine Warnungen zu unbehandelten Ablehnungen.

Grenzen und Prüfbasis

Ein Abbruch ist kein Fehlerzustand; ein AbortError von einem abgebrochenen Fetch sollte erkannt und ignoriert, nicht gemeldet werden. Das beschriebene Verhalten folgt der zitierten Dokumentation; es wird keine Messung behauptet.