Bei der Programmierung einer Anwendung müssen Sie unter Umständen wissen, wo Sie sich in Ihrem Code befinden, insbesondere wenn eine Methode andere Methoden aufruft, die wiederum andere Methoden aufrufen können. Aus diesem Grund ist es sehr hilfreich, während des Debugging-Prozesses die Methodenkette oder die Aufrufkette zu sehen. Hierfür bietet 4D v17 R6 den neuen Get call chain Befehl zur Verfügung, der Ihnen einen Einblick in den ausgeführten Code gibt. Jetzt müssen Sie nicht mehr befürchten, sich zu verirren!

Der Befehl gibt eine Sammlung von Objekten zurück. Jedes Objekt stellt einen Ausführungsschritt dar, der durch seine Datenbank, den Methodentyp, den Methodennamen und die Aufrufzeile beschrieben wird. Er kann in allen Kontexten der Codeausführung verwendet werden, sowohl im interpretierten als auch im kompilierten Modus.

BEISPIEL

So wird es sehr einfach, die Fehlerquelle zu finden. Siehe die folgende Aufrufkette mit ON ERR CALL:

C_OBJECT
// Store the error in a file located in the database logs folder
$fileFolderfk logs folder($error;$file)
C_COLLECTION ($_callChain)

$_callChain :=Get call chain

$error :=New object
$error .timestamp:=Timestamp
$error .method:=Error method
$error .error:=Error
$error.line:=Error line
$error.deep:=$_callChain.length
$error.callChain:=$_callChain
xml-file("error_"+Generate UUID+".json")
$file .setText(JSON Stringify($error))


Und hier sind einige Ergebnisse:

[{
    "timestamp": "2019-05-21T21:54:16.748Z",
    "method": "openDocument",
    "error": -43,
    "line": 3,
    "deep": 5,
    "callChain": [{
        "type": "projectMethod",  
        "name": "onError",
        "line": 3,
        "database": "Host_Database"
    }, {
        "type": "projectMethod",  
        "name": "openDocument",
        "line": 3,
        "database": "Host_Database"
    }, {
        "type": "projectMethod",  
        "name": "executeHostMethod",
        "line": 2,
        "database": "Component_Database"
    }, {
        "type": "formObjectMethod",  
        "name": "detailForm.openButton",
        "line": 1,
        "database": "Host_Database"
    }, {
        "type": "projectMethod",  
        "name": "showDetailForm",
        "line": 7,
        "database": "Host_Database"
    }]
}]

Ok. Wie können wir das also lesen? Das ist ziemlich einfach:

• Das Protokoll wurde in der dritten Zeile der onError-Methode der Host-Datenbank geschrieben,
• Sie wurde von der dritten Zeile der openDocument-Methode der Wirtsdatenbank aufgerufen,
• die von der zweiten Zeile der Methode executeHostMethod der Komponentendatenbank aufgerufen wurde,
• die von der ersten Zeile der Formularobjektmethode detailForm.openButton der Wirtsdatenbank aufgerufen wurde,
• die von der dritten Zeile der showDetailForm-Methode der Wirtsdatenbank aufgerufen wurde.

VERWENDUNGSFÄLLE

Es gibt verschiedene Anwendungsfälle für diesen Befehl, hier nur einige davon:

• Fehlerprüfung – Sie verwenden wahrscheinlich bereits „on error“-Methoden, die ein Fehlerprotokollsystem enthalten. Vor 4D v17 R6 konnten Sie nur den Fehlercode, die Fehlermethode und die Zeile, die den Fehler verursachte, abrufen. Wenn die Methode von mehreren Stellen in Ihrem Code aufgerufen wird, kann es ziemlich schwierig sein, den Kontext zu verstehen, der den Fehler erzeugt hat. Jetzt können Sie die gesamte Aufrufkette abrufen!
• Analysieren – Eine Methode wird von mehreren anderen Methoden aus aufgerufen und Sie möchten wissen, wo sie in einer Produktionsumgebung am häufigsten aufgerufen wird. Sie können nun die Aufrufkette der Methode protokollieren und die Ergebnisse später analysieren, ohne Dutzende von Codezeilen schreiben zu müssen. Um eine Verlangsamung der Leistung zu vermeiden, verwenden Sie den Befehl einfach nicht in allen Ihren Methoden!

• NICHT FÜR KONDITIONELLE ENTWICKLUNG – Beachten Sie, dass diese Funktion für Debugging- und/oder Optimierungszwecke gedacht ist. Sie ist NICHT für die bedingte Entwicklung auf der Grundlage von Aufrufermethoden gedacht.

BEREICHSPRÜFUNG

Get call chain kann sowohl im interpretierten als auch im kompilierten Modus ausgeführt werden. Der Befehl erfordert zusätzliche Informationen, die vom 4D Compiler erzeugt werden, wenn die Bereichsprüfung aktiviert ist. Da die Deaktivierung dieser Option gefährlich sein kann (und zu Abstürzen führen kann), haben wir sie aus den Datenbankeinstellungen entfernt. Auf diese Weise ist sie immer aktiviert.

Sie können jedoch weiterhin die entsprechenden Kommentare in Ihrem genehmigten und robusten Code verwenden:

• //%R- zum Deaktivieren der Bereichsprüfung in der Zeile
• //%R+ zur Aktivierung der Bereichsprüfung in der Zeile