TypeScript Academy · Lektion

Fehlermeldungen in DSLs auf Typebene

Geben Sie DSL-Nutzern hilfreiche Compilerfehler aus.

Fehlermeldungen in DSLs auf Typebene ist eine kostenlose TypeScript Academy-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des TypeScript Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der TypeScript Academy-Kurs umfasst insgesamt 4 Lektionen.

Hilfreiche Fehlermeldungen in Type-Level-DSLs

Der schwierigste Teil einer DSL auf Typebene besteht darin, Fehler verständlich zu machen. Unverfälschte never- oder "not assignable"-Fehler verwirren die Benutzer. Mit Branded-Fehlertypen und gezielt formulierten never-Meldungen geben wir aussagekräftige Fehler aus.

Das Problem mit never

Wenn eine Validierung fehlschlägt und zu never aufgelöst wird, meldet der Compiler "Argument of type X is not assignable to never". Das erklärt dem Benutzer nicht, warum der Fehler aufgetreten ist. Das geht besser.

Branded-Fehlertypen

Geben Sie statt einfachem never einen eindeutig strukturierten Fehlertyp zurück, der eine für Menschen lesbare Meldungszeichenfolge in seinem Typ enthält.

type TypeError<Msg extends string> = {
  readonly __error: Msg;
};

type E = TypeError<"Column 'foo' does not exist">;

Fehler aus der Validierung zurückgeben

Ein Validator gibt entweder den Typ des gültigen Werts oder einen Branded-Fehlertyp zurück, der das Problem beschreibt. Die Prüfung „enthält einen Punkt“ ist ein Template-Literal-Muster (im echten Code mit Backticks); wir bezeichnen es als HasDot.

// HasDot<S> is the backtick pattern: any text, ".", any text.

type Validate<S extends string> =
  S extends HasDot
    ? S
    : TypeError<"Path must contain a dot, e.g. user.name">;

Den Fehler sichtbar machen

Schränken Sie den Parameter so ein, dass bei der Übergabe eines Werts, der der Fehlermarke nicht zugewiesen werden kann, die Meldung ausgegeben wird. Der Fehlertyp erscheint dann direkt in der Compiler-Ausgabe.

declare function path<S extends string>(
  p: Validate<S> extends TypeError<infer M> ? TypeError<M> : S
): void;

path("oops");
// Error message includes: __error: "Path must contain a dot..."

Mehrere Fehler unterscheiden

Unterschiedliche Fehler liefern unterschiedliche Meldungen. So erhalten Benutzer konkrete Hinweise statt einer pauschalen Ablehnung. HasDot ist erneut das Backtick-Template-Literal-Muster für „enthält einen Punkt“.

type Check<S extends string> =
  S extends "" ? TypeError<"Path cannot be empty">
  : S extends HasDot ? S
  : TypeError<"Missing dot separator">;

never mit einem Kniff

Eine weitere Technik kombiniert eine Wertposition mit einer literalen Meldung, sodass sie beim Überfahren mit dem Mauszeiger sichtbar wird. Dazu schneiden Sie den fehlerhaften Typ mit einem beschrifteten Objekt.

type Invalid<M extends string> = { error: M } & never;
// using never keeps it unassignable while the label hints the cause

Fehler in Fluent-DSLs

Geben Sie in einer verketteten DSL für den nächsten ungültigen Schritt einen mit einem Fehler versehenen Typ statt einer gültigen Stufe zurück. So zeigt der Editor die Meldung genau an der Stelle des Fehlers an.

interface Stage {
  // calling done() before where() yields a labeled error
  done(): TypeError<"Call .where() before .done()">;
}

Meldungen kurz halten

Lange Meldungstypen blähen die Compiler-Ausgabe auf und verlangsamen die Werkzeuge. Bevorzugen Sie kurze, direkt umsetzbare Formulierungen. Fügen Sie das fehlerhafte Token ein, wenn dies mit geringem Aufwand möglich ist, vermeiden Sie aber umfangreiche Interpolationen.

Fehlermeldungen testen

Schreiben Sie Tests auf Typebene, die für bekannte fehlerhafte Eingaben das Auftreten der Fehlermarke überprüfen. So verschlechtern Refactorings die Entwicklererfahrung nicht unbemerkt.

type Expect<T extends true> = T;
type _t = Expect<Validate<"oops"> extends TypeError<any> ? true : false>;

Warum das wichtig ist

Eine DSL ist nur so gut wie ihre Fehlermeldungen. Branded-Fehlertypen verwandeln kryptische never-Fehler in selbsterklärende Meldungen und verbessern dadurch die Nutzung Ihrer API auf Typebene erheblich.

Kurztest

Überprüfen Sie Ihr Verständnis von Fehlermeldungen auf Typebene.

Zusammenfassung

Damit DSLs auf Typebene gut nutzbar sind, ersetzen Sie einfaches never durch Branded-Fehlertypen, die lesbare Meldungen enthalten. Validatoren geben entweder den gültigen Typ oder eine spezifische Fehlermarke zurück; durch die Einschränkung von Parametern erscheint die Meldung in der Compiler-Ausgabe. Halten Sie die Meldungen kurz und testen Sie sie.

Häufig gestellte Fragen

Ist die Lektion „Fehlermeldungen in DSLs auf Typebene“ kostenlos?

Ja — der vollständige Text von „Fehlermeldungen in DSLs auf Typebene“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des TypeScript Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der TypeScript Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Fehlermeldungen in DSLs auf Typebene“?

Geben Sie DSL-Nutzern hilfreiche Compilerfehler aus. Du übst TypeScript Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um TypeScript Academy zu starten?

Keine Vorkenntnisse erforderlich. TypeScript Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Fehlermeldungen in DSLs auf Typebene“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser TypeScript Academy-Lektion Code schreiben und ausführen?

Ja. Jede TypeScript Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

← Zurück zu TypeScript Academy