Übersetzung der englischen Originalseite. Bei Abweichungen gilt die englische Fassung.
Fehler und problem+json
Fehler sind in DaloyJS ein vollwertiger Bestandteil. Jeder geworfene HttpError wird zu problem+json nach RFC 9457 serialisiert, mit einer stabilen type-URI, einer Request-ID und dem passenden Content-Type.
- 01Handlerthrow new NotFoundError(...)beliebige Unterklasse von HttpError
- 02FrameworkAuf Felder nach RFC 9457 abbildentype · title · status · detail
- 03Produktion5xx-Details schwärzennur sichtbar, wenn env development oder test ist
- 04ÜbertragungSerialisierte Antwortapplication/problem+json + x-request-id
Eingebaute Fehlerklassen
TooManyRequestsError und ServiceUnavailableError validieren retryAfterSeconds auf dieselbe Weise: Alles außer einer nicht negativen sicheren Ganzzahl löst bei der Konstruktion einen RangeError aus, damit ein NaN aus einer fehlenden Umgebungsvariable nie zu einem ungültigen Retry-After-Header wird. RequestTimeoutError (die Frist aus requestTimeoutMs, siehe requestTimeoutStatus, auf Englisch) ist seit 1.16.0 für jede Statusvariante no-store, damit ein gemeinsamer Cache nicht weiter ein 503/504 ausliefert, nachdem sich das Backend erholt hat. Ein bloßes new HttpError(status, …) erhält als Problem-type die URI https://httpstatuses.io/<status>; die eingebauten Klassen tragen stabile URIs der Form https://daloyjs.dev/errors/<slug>.
Im Handler werfen
Übertragungsformat
Die Request-ID wird dem Client an zwei Stellen zurückgegeben: im Response-Header x-request-id und (gemäß RFC 9457 §3.1) im Feld instance des Problem-Dokuments als URN der Form urn:request:<uuid>. Es gibt keine Eigenschaft requestId auf oberster Ebene; Clients sollten den Header lesen oder die URN aus instance parsen.
Schwärzung in Produktion
DaloyJS entfernt das Feld detail bei jeder 5xx-Antwort, sofern die Umgebung nicht eindeutig development oder test ist, damit interne Fehlermeldungen und SQL-Fragmente nicht an Clients gelangen. Der vollständige Fehler geht weiterhin an Ihren Logger und an den onError-Hook.
| Konfiguration | 5xx-detail |
|---|---|
env: "development" oder env: "test" | sichtbar |
kein env, NODE_ENV=development oder test | sichtbar |
kein env, NODE_ENV nicht gesetzt, leer oder etwas anderes | geschwärzt |
env: "production", production: true oder NODE_ENV=production | geschwärzt |
production: false bei nicht gesetztem NODE_ENV | geschwärzt |
Eine nicht gesetzte Umgebung schlägt absichtlich sicher fehl. Edge-Laufzeiten wie Cloudflare Workers und Deno Deploy haben kein NODE_ENV, und würde man das als development behandeln, gingen Exception-Meldungen an Clients. daloy dev setzt NODE_ENV=development für seinen Kindprozess, wenn Sie es nicht gesetzt haben, sodass die lokale Entwicklung die Details weiterhin zeigt. Fehler, die Sie selbst serialisieren (zum Beispiel ein Response-Body, der in einem catch-Block aus err.message gebaut wird), werden nicht geschwärzt. Werfen Sie sie stattdessen, oder werfen Sie einen HttpError mit einem unbedenklichen detail.
Eigene Fehlerklassen
Die eingebauten Klassen oben setzen alle einen type der Form https://daloyjs.dev/errors/<slug>. Ein einfacher HttpError, der ohne type geworfen wird, fällt auf https://httpstatuses.io/<status> zurück. Eigene Middleware des Frameworks, die mit 503 antwortet (loadShedding(), concurrencyLimit(), requestTimeoutStatus: 503), setzt ihren eigenen daloyjs.dev-Typ, daher gilt der Fallback nur für Fehler, die Sie selbst erzeugen. Setzen Sie type, wenn Clients darauf reagieren, oder verwenden Sie eine eingebaute Klasse:
Dienst nicht verfügbar
Für einen Wartungsmodus, den Ausfall einer Abhängigkeit oder eine Instanz, die gerade geleert wird, werfen Sie ServiceUnavailableError. Er antwortet mit 503, einem stabilen Typ https://daloyjs.dev/errors/service-unavailable, einem optionalen Retry-After und cache-control: no-store, damit ein CDN den Ausfall nicht weiter ausliefert, nachdem Sie sich erholt haben.
retryAfterSeconds muss eine nicht negative Ganzzahl sein. Alles andere (NaN aus einer fehlenden Umgebungsvariable, -1, 1.5) löst einen RangeError aus, statt einen fehlerhaften Retry-After-Header zu senden.
Eigenes onError
Zuletzt aktualisiert: