Lorsque vous programmez une application, vous pouvez avoir besoin de savoir où vous en êtes dans votre code, notamment lorsqu’une méthode appelle d’autres méthodes, qui peuvent ensuite appeler d’autres méthodes. C’est pourquoi il est très utile de voir la chaîne des méthodes, ou la chaîne d’appel, pendant le processus de débogage. Pour cela, 4D v17 R6 fournit la nouvelle commande Get call chain pour vous donner un aperçu du code exécuté. Désormais, vous n’aurez plus à craindre de vous perdre !

La commande renvoie une collection d’objets. Chaque objet représente une étape d’exécution décrite par sa base de données, son type de méthode, son nom de méthode et sa ligne d’appel. Elle peut être utilisée dans tous les contextes d’exécution du code, aussi bien en mode interprété que compilé.

EXEMPLE

Ainsi, trouver la source d’une erreur devient très facile. Voyez la chaîne d’appel suivante avec 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))


Et voici quelques résultats :

[{
    "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. Alors comment pouvons-nous lire ceci ? C’est assez simple :

• Le journal a été écrit à la troisième ligne de la méthode onError de la base de données hôte,
• qui a été appelée par la troisième ligne de la méthode openDocument de la base de données hôte,
• Qui a été appelée par la deuxième ligne de la méthode executeHostMethod de la base de données des composants,
• qui a été appelée par la première ligne de la méthode de l’objet de formulaire detailForm.openButton de la base de données hôte,
• qui a été appelée par la troisième ligne de la méthode showDetailForm de la base de données hôte.

CAS D’UTILISATION

Il existe différents cas d’utilisation de cette commande, en voici quelques-uns :

• Vérification des erreurs – Vous utilisez probablement déjà les méthodes « on error » qui incluent un système de journal des erreurs. Avant 4D v17 R6, vous ne pouviez récupérer que le code d’erreur, la méthode d’erreur et la ligne générant l’erreur. Si la méthode est appelée à plusieurs endroits dans votre code, il pouvait être assez difficile de comprendre le contexte qui a généré l’erreur. Maintenant, vous pouvez récupérer la chaîne d’appel complète !
• Analyse – Une méthode est appelée depuis plusieurs autres méthodes et vous voulez savoir où elle est appelée le plus souvent, dans un environnement de production. Vous pouvez maintenant enregistrer la chaîne d’appel de la méthode et analyser les résultats plus tard, sans écrire des dizaines de lignes de code. Pour éviter de ralentir les performances, il suffit de ne pas utiliser la commande dans toutes vos méthodes !

• PAS POUR LE DÉVELOPPEMENT CONDITIONNEL – Gardez à l’esprit que cette fonctionnalité est destinée au débogage et/ou à l’optimisation. Elle n’est PAS destinée au développement conditionnel basé sur les méthodes de l’appelant.

VÉRIFICATION DE LA PORTÉE

Get call chain peut être exécuté à la fois en mode interprété et compilé. La commande requiert des informations supplémentaires produites par le compilateur 4D lorsque le contrôle d’étendue est activé. Comme la désactivation de cette option pouvait être dangereuse (entraînant des plantages), nous l’avons supprimée des paramètres de la base de données. De cette façon, elle est toujours activée.

Cependant, vous pouvez toujours utiliser les commentaires correspondants dans votre code approuvé et robuste :

• //%R- pour désactiver la vérification de la portée de la ligne
• //%R+ pour activer la vérification de la portée de la ligne