Quando si programma un’applicazione, può essere necessario sapere in quale punto del codice ci si trova, soprattutto quando un metodo chiama altri metodi, che a loro volta possono chiamare altri metodi. Per questo motivo è molto utile vedere la catena dei metodi, o la catena delle chiamate, durante il processo di debug. A questo scopo, 4D v17 R6 mette a disposizione il nuovo comando Get call chain per dare una visione del codice eseguito. Ora non dovrete più preoccuparvi di perdervi!

Il comando restituisce un insieme di oggetti. Ogni oggetto rappresenta una fase di esecuzione descritta dal suo database, dal tipo di metodo, dal nome del metodo e dalla linea di chiamata. Può essere utilizzato in tutti i contesti di esecuzione del codice, sia in modalità interpretata che compilata.

ESEMPIO

In questo modo, trovare l’origine di un errore diventa molto semplice. Si veda la seguente catena di chiamate con 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))


Ed ecco alcuni risultati:

[{
    "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. Come possiamo leggere questo? È piuttosto semplice:

• Il log è stato scritto alla terza riga del metodo onError del database host,
• È stato chiamato dalla terza riga del metodo openDocument del database host,
• che è stato chiamato dalla seconda riga del metodo executeHostMethod del database del componente,
• che è stato chiamato dalla prima riga del metodo dell’oggetto form del database host detailForm.openButton,
• che è stato chiamato dalla terza riga del metodo showDetailForm del database host.

CASI D’USO

Esistono diversi casi d’uso per questo comando, eccone alcuni:

• Controllo degli errori – Probabilmente utilizzate già i metodi “on error” che includono un sistema di log degli errori. Prima di 4D v17 R6, era possibile recuperare solo il codice di errore, il metodo di errore e la riga che ha generato l’errore. Se il metodo viene chiamato da più punti del codice, potrebbe essere difficile capire il contesto che ha generato l’errore. Ora è possibile recuperare l’intera catena di chiamate!
• Analisi – Un metodo viene chiamato da diversi altri metodi e si vuole sapere dove viene chiamato più spesso, in un ambiente di produzione. Ora è possibile registrare la catena di chiamate del metodo e analizzare i risultati in seguito, senza scrivere decine di righe di codice. Per evitare di rallentare le prestazioni, basta non usare il comando in tutti i metodi!

• NON PER LO SVILUPPO CONDIZIONALE – Tenete presente che questa funzione serve a scopi di debug e/o ottimizzazione. NON è per lo sviluppo condizionale basato sui metodi del chiamante.

CONTROLLO DELL’INTERVALLO

Get call chain può essere eseguito sia in modalità interpretata che compilata. Il comando richiede informazioni aggiuntive prodotte dal compilatore 4D quando il controllo dell’intervallo è attivato. Poiché la disattivazione di questa opzione potrebbe essere pericolosa (con conseguenti arresti anomali), l’abbiamo rimossa dalle impostazioni del database. In questo modo, è sempre attivata.

Tuttavia, è ancora possibile utilizzare i commenti corrispondenti nel codice approvato e robusto:

• //%R- per disattivare il controllo dell’intervallo dalla riga
• //%R+ per attivare il controllo dell’intervallo dalla riga