Fehlermeldungen

createTError

Erzeugt eine an den Locales-Typ gebundene Error-Klasse. Signatur siehe createTError in der API-Referenz. Die Meldung wird im Konstruktor aufgelöst, sodass error.message bereits die übersetzte Meldung enthält.

import { createTError } from "@one-unity/library/ou.sp.I18n";
import type { Locales } from "./ou.sp.ptpINV.installer.step.globalPropertiesLocales";

const TError = createTError<Locales>();

function guardAdditionalVerification(): boolean {
    try {
        if (!hasSecondVerifier) {
            throw new TError((l) => l.workflow.ptpInvoice.guard.additionalVerification.error.sameUser);
        }
        return true;
    } catch (error) {
        context.errorMessage = error.message;
        return false;
    }
}

Der catch-Block bleibt unverändert

Weil TError die Meldung im Konstruktor auflöst, ist die im Codebase übliche Konvention catch (error) { context.errorMessage = error.message; } bereits korrekt lokalisiert. An bestehenden catch-Blöcken muss beim Migrieren nichts geändert werden.

Signaturen

Der Konstruktor nimmt entweder ein Options-Objekt oder die Werte einzeln — beide Überladungen und die Felder von TErrorOptions stehen unter TError und TErrorOptions.

Zwei Felder bestimmen das Verhalten über die reine Übersetzung hinaus: logLevel steuert, mit welchem Level die Meldung protokolliert wird (Standard ERROR, NONE unterdrückt es), und cause hängt die technische Ursache unübersetzt an — siehe unten.

Technische Ursache anhängen

Nicht handlungsrelevante technische Fehler werden laut ADR 025 nicht übersetzt. Muss der Nutzer trotzdem informiert werden, liefert der Locale-Key den generischen Rahmen und cause den unübersetzten technischen Grund:

if (!docFile.sync()) {
    throw new TError({
        key: (l) => l.ptpInvoice.error.saveFailed,
        cause: docFile.getLastError(),
    });
}
// error.message === "Datei konnte nicht gespeichert werden: FileNotFound (id=42)"

cause akzeptiert einen Error, einen String (etwa das Ergebnis von getLastError()) oder einen beliebigen anderen Wert. Ist er leer, null oder undefined, wird nichts angehängt. Der ursprüngliche Wert bleibt als error.cause erhalten und kann weiter oben in der Aufrufkette ausgewertet werden.

Logging

TError protokolliert seine Meldung bereits beim Erzeugen über otrLogger, mit dem Kontext TError.

Kein doppeltes Logging

Steht neben einem throw noch ein eigener logger.error(...)-Aufruf, entfällt dieser beim Umbau auf TError — sonst steht die Meldung zweimal im Log. Umgekehrt gilt: wird ein TError erzeugt und anschließend verworfen, ohne geworfen zu werden, ist er trotzdem im Log.

Für den Fall, dass gar nicht protokolliert werden soll:

throw new TError({ key: (l) => l.ptpInvoice.error.saveFailed, logLevel: "NONE" });