Fehlermodell

Jeder Fehler taucht als abgelehntes Versprechen oder über das onError-Abo auf — niemals als ungefangene Ausnahme.

1. TimeoutError

Die exportierte TimeoutError-Klasse unterscheidet die Zeitüberschreitungen der Host-Wartung von gewöhnlichen Fehlern:

class TimeoutError extends Error {
    readonly operation: string;  // die abgelaufene, erwartete Operation
    readonly timeoutMs: number;  // die überschrittene konfigurierte Grenze
}
// error.name === 'DashletTimeoutError'
// error.message === '<operation> timed out after <timeoutMs>ms'

Prüfen Sie auf Zeitüberschreitung mit instanceof TimeoutError (exportiert neben DEFAULT_TIMEOUT_MS und withTimeout) oder über den Namen 'DashletTimeoutError'.

Die Vorgabe ist DEFAULT_TIMEOUT_MS = 5000, konfigurierbar über DashletOptions.timeoutMs (siehe DashletOptions).

2. Begrenzte Antwort-Semantik

Der enaio-Vertrag definiert keine Antwortgarantie. Jede Host-Interaktion, die auf eine Antwort wartet — die init-Wartephase und jeder Methodenaufruf — wird in eine konfigurierte Antwortzeit eingebettet: Das Rennen löst sich mit dem Arbeitsergebnis, wenn dieses zuerst eintritt, und wird andernfalls mit einer TimeoutError abgelehnt; der Timer wird immer aufgeräumt. Eine Zeitüberschreitung ist damit ein abfangbarer, beobachtbarer Fehlerzustand — niemals ein endloses Hängen. Das zugrunde liegende Primitiv ist withTimeout.

3. Fehlerquelle → Form

Fehlerquelle Ablehnungsform

Host antwortet nicht innerhalb von timeoutMs

TimeoutError (name 'DashletTimeoutError')

Webclient-Host antwortet mit einer { error }-Nutzlast

Ein Wrapper-Fehler mit name 'DashletHostError' um den Host-Fehler (der Aufruf bleibt durch die Antwortzeit begrenzt)

Rich-Client-Bridge-Aufruf wirft eine Ausnahme, oder die Bridge-Methode fehlt

Deskriptive Ablehnung — ein abgelehntes Versprechen, niemals eine ungefangene Ausnahme

Ungültiger Optionswert bei der Installation (z. B. ein expectedOrigin, der weder URL noch Mitglied der File-Origin-Gruppe ist; "*" wird immer abgelehnt)

Deskriptive TypeError

Unbekannte Methode über call() im Rich Client

Deskriptive TypeError

Jede portable Methode oder call() im Standalone

Begrenztes TimeoutError — es existiert kein Antwortweg, sodass die Aufrufer einen Fallback rendern können, statt zu hängen

Anderer Code hat window.osDashletInit ersetzt (nur Rich Client)

Keine Ablehnung: ein einfaches Error pro Dashlet-Instanz über onError, Meldungspräfix Dashlet: window.osDashletInit was replaced by other code

Zwei Klärungen:

  • Die Standalone-init-Wartephase ist kein Fehler — dashlet.init löst sich (innerhalb von detectionTimeoutMs) mit dem beobachtbaren, abgemilderten Standalone-Kontext auf; nur die Methodenaufrufe werden abgelehnt.

  • Ein Webclient-Host-Fehler lehnt nur den jeweiligen wartenden Aufruf ab; er zerstört das Dashlet nicht und beeinflusst spätere Aufrufe nicht.