Fehler überall aufspüren

Das Fehlermanagement ist in allen Sprachen oft ein einschränkender Teil der Entwicklung. Wenn Sie in 4D vergessen, eine Methode zur Fehlerbehandlung in einem neuen Prozess/Worker aufzurufen, oder Komponenten verwenden, die keine Fehler behandeln, kann der eingebaute 4D Fehlerdialog für den Endbenutzer erscheinen. 4D Entwickler möchten alle Fehler in allen Kontexten abfangen, um die Anzeige dieses eingebauten 4D Fehlerdialogs zu vermeiden.

Sehen wir uns an, wie wir dieses Verhalten mit 4D v19 R8 steuern können.

Demo zur Fehlerbehandlung

Global Error Handler

Bis jetzt war es „best Praxis“ für die Behandlung von Fehlern in einem Ausführungskontext die Verwendung des ON ERR CALL Befehl zu verwenden und den Methodenhandler als Parameter zu übergeben. Diese Fehlermethode wurde jedoch nur im aktuellen Prozesskontext aufgerufen.
Ab 4D v19 R8 können Sie auch einen globalen Fehlerhandler definieren, der für alle Ausführungskontexte effizient ist. Wenn Sie vergessen haben, einen lokalen Fehler-Handler in einem neuen Prozess/Worker zu definieren, wird automatisch der globale Fehler-Handler aufgerufen. Um Ihre Anwendung zu schützen, können Sie Ihren globalen Error-Handler z. B. in der Datenbankmethode On Startup definieren.

ON ERR CALL("myGlobalErrorHandler"; ek global)

Die Übergabe einer Fehlermethode, die im aktuellen Prozess aufgerufen wird, ist immer noch effizient. Wir haben sie in Local Error Handler umbenannt.

ON ERR CALL("myLocalErrorHandler")
// equivalent to:
ON ERR CALL("myLocalErrorHandler"; ek local)

Beachten Sie, dass die lokale Fehlerbehandlung auch dann aufgerufen wird, wenn eine globale Fehlerbehandlung definiert ist, so dass Ihre definierten lokalen Fehlerbehandlungen wie gewohnt ausgeführt werden. Der globale Errorhandler wird nur aufgerufen, wenn im aktuellen Ausführungskontext kein lokaler Errorhandler definiert ist.

ORDA-Funktionen und berechnete Attribute auf dem 4D Server

Wenn eine ORDA Funktion oder ein berechnetes Attribut in einer Client-Anwendung verwendet wird, wird es auf der 4D Server Seite ausgeführt. Wenn diese Funktionen oder berechneten Attribute also keinen lokalen Fehlerhandler definieren und Fehler auslösen, wird der eingebaute 4D Fehlerdialog auf dem 4D Server angezeigt, wenn sie nicht headless ausgeführt werden.
Um dies zu vermeiden, können Sie nun einen globalen Fehlerhandler auf der Serverseite in der Datenbankmethode On Server Startup (Beispiel) definieren:

ON ERR CALL("myServerGlobalErrorHandler"; ek global)

Komponenten

Für Sie als Komponentenentwickler ist es jetzt einfacher, Fehler zu behandeln. Sie müssen nur Ihren globalen Error Handler in der Datenbankmethode On Host Database Event (z.B. im On before host database startup event) definieren, um sicherzustellen, dass kein Fehler den eingebauten 4D Fehlerdialog in der Host-Datenbank anzeigt! Auf diese Weise wird bei allen von der Komponente erzeugten Fehlern der globale Fehlerhandler der Komponente aufgerufen, ohne dass es zu Nebenwirkungen in der Host-Datenbank kommt.

Als Komponentenbenutzer können Sie Ihre Anwendung sicherer machen, indem Sie Komponentenfehler behandeln, die nicht im Ausführungskontext der Komponente abgefangen wurden. Wenn Sie Komponenten verwenden, die ihre eigenen Fehler nicht korrekt behandeln, können Sie diese auf diese Weise behandeln, und es wird kein eingebauter 4D Fehlerdialog mehr erscheinen. Um eine Fehlerbehandlungsmethode für eine Komponente zu installieren, verwenden Sie einfach den entsprechenden Parameter wie folgt:

ON ERR CALL("myComponentErrorHandler"; ek errors from components)

Dies ist auch ein globaler Error-Handler, aber für Fehler, die von Komponenten nicht abgefangen werden, so dass Sie spezielle Funktionen für diese entwickeln können. Beachten Sie, dass die Fehlersystemvariablen(Fehler, Fehlermethode, Fehlerzeile und Fehlerformel) in diesem Komponenten-Fehlerbehandlungsprogramm nicht verfügbar sind, da Fehler aus einem anderen Ausführungskontext stammen. Der Fehlerstapel ist jedoch weiterhin verfügbar.

GEMEINSAME VERHALTENSWEISEN

Fehler-Stack

Wir haben auch einen neuen Befehl eingeführt, um den gesamten Fehlerstapel zu erhalten: Last errors. Dieser Befehl gibt eine Collection zurück, in der jedes Element ein Fehler des gesamten Stapels ist, wobei jeder Fehler Informationen über die Fehlernummer, die Meldung und die interne Komponentensignatur enthält.

Abrufen des aktuellen ERROR-handlers

Der Befehl Method called on the error Befehl lässt nun einen optionalen Parameter zu, um den globalen Error-Handler und den Komponenten-Error-Handler abzurufen, wie in diesem Beispiel:

$localHandler:=Method called on error
$globalHandler:=Method called on error(ek global)
$componentHandler:=Method called on error(ek errors from component)

Abbruch des Fehlers

Unabhängig davon, welcher Handler ausgeführt wird, ist der ABORT Befehl immer praktisch und erlaubt es Ihnen, den Code wie gewohnt zu unterbrechen.

Sie können alle diese neuen Verhaltensweisen mit dem obigen HDI testen.