La gestione degli errori è spesso una parte vincolante dello sviluppo in tutti i linguaggi. In 4D, se si dimentica di chiamare un metodo di gestione degli errori in un nuovo processo/lavoratore o si utilizzano componenti che non gestiscono gli errori, all’utente finale può apparire la finestra di dialogo di errore integrata in 4D. Gli sviluppatori di 4D vorrebbero catturare tutti gli errori in tutti i contesti per evitare di visualizzare la finestra di dialogo di errore integrata in 4D.
Vediamo come gestire questo comportamento con 4D v19 R8.
Dimostrazione della gestione degli errori
Gestore globale degli errori
Finora, la pratica migliore per gestire gli errori in un contesto di esecuzione era quella di utilizzare il comando ON ERR CALL e passare il gestore del metodo come parametro. Tuttavia, questo metodo di errore veniva chiamato solo nel contesto del processo corrente.
A partire da 4D v19 R8, è possibile definire un gestore di errori globale che sarà efficiente per tutti i contesti di esecuzione. Se si dimentica di definire un gestore di errori locale in un nuovo processo/lavoratore, il gestore di errori globale verrà invocato automaticamente. Quindi, per salvare l’applicazione, si può definire il gestore di errori globale nel metodo On Startup del database, ad esempio.
ON ERR CALL("myGlobalErrorHandler"; ek global)Passare un metodo di errore da richiamare nel processo corrente è ancora efficiente. Lo abbiamo rinominato gestore di errori locale.
ON ERR CALL("myLocalErrorHandler")
// equivalent to:
ON ERR CALL("myLocalErrorHandler"; ek local)
Si noti che il gestore di errori locale viene comunque invocato, se definito, anche se è definito un gestore di errori globale, quindi i gestori di errori locali definiti verranno eseguiti come di consueto. Il gestore di errori globale viene invocato solo se nel contesto di esecuzione corrente non è definito alcun gestore di errori locale.
Funzioni ORDA e attributi calcolati sul server 4D
Come è noto, quando una funzione ORDA o un attributo calcolato viene utilizzato in un’applicazione client, viene eseguito sul lato Server 4D. Pertanto, se queste funzioni o attributi calcolati non definiscono un gestore di errori locale e lanciano errori, la finestra di dialogo di errore integrata in 4D viene visualizzata sul Server 4D quando non viene eseguita in modalità headless.
Per evitare ciò, è ora possibile definire un gestore di errori globale sul lato server nel metodo On Server Startup del database, ad esempio:
ON ERR CALL("myServerGlobalErrorHandler"; ek global)Componenti
Come sviluppatore di componenti, ora è più facile gestire gli errori. È sufficiente definire il gestore di errori globale nel metodo di database On Host Database Event (ad esempio, nell’evento On before host database startup ) per garantire che nessun errore visualizzi la finestra di dialogo di errore integrata di 4D nel database host! In questo modo, tutti gli errori generati dal componente richiameranno il gestore di errori globale del componente senza alcun effetto collaterale sul database host.
L’utente di un componente può rendere più sicura la propria applicazione gestendo gli errori del componente che non sono stati catturati nel contesto di esecuzione del componente. In questo modo, se si utilizzano componenti che non gestiscono correttamente i propri errori, è possibile gestirli e non apparirà più la finestra di dialogo degli errori di 4D. Per installare un metodo di gestione degli errori di un componente, è sufficiente utilizzare il parametro corrispondente in questo modo:
ON ERR CALL("myComponentErrorHandler"; ek errors from components)Anche questo è un gestore di errori globale, ma è dedicato agli errori non catturati dai componenti, in modo da poter sviluppare cose specifiche per questi. Si noti che le variabili di sistema degli errori(errore, metodo di errore, riga di errore e formula di errore) non sono disponibili in questo gestore di errori di un componente, perché gli errori provengono da un altro contesto di esecuzione. Ma lo stack degli errori è ancora disponibile.
COMPORTAMENTI COMUNI
Pila degli errori
Abbiamo anche introdotto un nuovo comando per ottenere l’intero stack di errori: Last errors. Questo comando restituisce un insieme in cui ogni elemento è un errore dell’intero stack, ogni errore contiene informazioni sul numero di errore, il messaggio e la firma del componente interno.
Ottenere il gestore di errori corrente
Il comando Method called on the error ammette ora un parametro opzionale per recuperare il gestore di errori globale e il gestore di errori del componente, come in questo esempio:
$localHandler:=Method called on error
$globalHandler:=Method called on error(ek global)
$componentHandler:=Method called on error(ek errors from component)Interruzione dell’errore
Indipendentemente dal gestore eseguito, il comando ABORT è sempre pratico e consente di interrompere il codice come di consueto.
È possibile testare tutti questi nuovi comportamenti con l’HDI di cui sopra.