01 · Problem
Wofür braucht man das?
JavaScript darf beliebige Werte werfen; Grenzen zwischen Bibliotheken, Workern oder JSON verlieren dadurch Namen, Ursache und zuverlässige Typen.
02 · Denkmodell
Das mentale Modell
Am Systemrand wird unknown einmal in eine serialisierbare Fehlerform überführt. Intern transportiert ein discriminated union Erfolg oder Fehler explizit.
Fängt Fehler und normalisiert problematische, zyklische oder asynchrone Fehlerwerte sicher. Das kompatible Ergebnisformat lässt Error als regulären Rückgabewert mehrdeutig. Ein markierter Result-Typ ist eine mögliche spätere Hauptversion.
03 · Kontrollfluss
Was passiert in welcher Reihenfolge?
- Synchronen Aufruf oder Promise in try/catch beziehungsweise await einschließen.
- Gefangenen unknown-Wert ohne weitere Throws in eine sichere Struktur umwandeln.
- Erfolg und Fehler über ein eindeutiges ok-Feld unterscheiden.
- An Prozessgrenzen nur JSON-sichere Felder übertragen und Ursachen begrenzen.
04 · Bauteile
Die entscheidenden Verträge
NormalizedError / toNormalizedErrorRepräsentiert unbekannte Fehlerwerte sicher.noThrow / isError / aggregateErrorsFängt asynchrone und synchrone Fehler, erkennt sie und kombiniert Meldungen.05 · Selbst bauen
Selbst implementieren
Ein explizites Result vermeidet die Mehrdeutigkeit zwischen Rückgabewert und Fehler.
- Result als Union mit ok: true oder ok: false definieren.
- unknown über instanceof und sichere String-Konvertierung normalisieren.
- Async-Aufrufe immer mit await im selben try-Block ausführen.
type Result<T> =
| { ok: true; value: T }
| { ok: false; error: { name: string; message: string; stack?: string } };
async function capture<T>(run: () => T | PromiseLike<T>): Promise<Result<T>> {
try { return { ok: true, value: await run() }; }
catch (value) {
const error = value instanceof Error ? value : new Error(String(value));
return { ok: false, error: { name: error.name, message: error.message, stack: error.stack } };
}
}06 · Verifizieren
Was solltest du testen?
- Error, String, null und ein Objekt mit werfender toString-Methode werden ohne Folgefehler normalisiert.
- Thenables und native Promises liefern dieselbe Result-Form.
- Ein regulär zurückgegebener Error bleibt durch ok: true eindeutig ein Wert.
Selbst ausprobieren
Formuliere die erste Prüfaussage als fehlschlagenden Test, implementiere die kleinste Korrektur und ergänze einen Grenzfall.
Error, String, null und ein Objekt mit werfender toString-Methode werden ohne Folgefehler normalisiert.
Ansatz vergleichen
Dein Test sollte beim gezielten Verletzen der Invariante fehlschlagen und nach der Korrektur wieder bestehen. Halte den Aufbau deterministisch und prüfe ein beobachtbares Ergebnis.
07 · Grenzen
Kompromisse und Stolperfallen
- Result macht Fehler im Typ sichtbar, erfordert aber explizites Branching an jedem Aufruf.
- Stacks helfen beim Debugging, können jedoch Pfade oder andere interne Daten verraten.
- Serialisierbare Fehler verlieren Prototyp und nicht standardisierte Eigenschaften.
Das kompatible Ergebnisformat lässt Error als regulären Rückgabewert mehrdeutig. Ein markierter Result-Typ ist eine mögliche spätere Hauptversion.
08 · Weiterdenken
Quellcode und verwandte Ideen
yarn tsx packages/ts-error/examples/basic.ts