La gestion des erreurs est souvent une partie contraignante du développement dans tous les langages. Dans 4D, si vous oubliez d’appeler une méthode de gestion des erreurs dans un nouveau process/worker ou si vous utilisez des composants qui ne gèrent pas les erreurs, le dialogue d’erreur intégré 4D peut apparaître à l’utilisateur final. Les développeurs 4D aimeraient intercepter toutes les erreurs dans tous les contextes afin d’éviter l’affichage de ce dialogue d’erreur intégré 4D.
Voyons comment nous pouvons gérer ce comportement avec 4D v19 R8.
Démonstration de la gestion des erreurs
Gestionnaire d’erreurs global
Jusqu’à présent, la meilleure pratique pour gérer les erreurs dans un contexte d’exécution était d’utiliser la commande ON ERR CALL et de passer la méthode de gestion en paramètre. Cependant, cette méthode d’erreur n’était appelée que dans le contexte du process en cours.
A partir de 4D v19 R8, vous pouvez également définir un gestionnaire d’erreur global qui sera efficace pour tous les contextes d’exécution. Si vous oubliez de définir un gestionnaire d’erreur local dans un nouveau process/worker, le gestionnaire d’erreur global sera invoqué automatiquement. Ainsi, pour sécuriser votre application, vous pouvez définir votre gestionnaire d’erreur global dans la méthode de la base de données On Startup, par exemple.
ON ERR CALL("myGlobalErrorHandler"; ek global)Le passage d’une méthode d’erreur à appeler dans le process courant est toujours efficace. Nous l’avons renommé « gestionnaire d’erreur local« .
ON ERR CALL("myLocalErrorHandler")
// equivalent to:
ON ERR CALL("myLocalErrorHandler"; ek local)
Notez que le gestionnaire d’erreurs local est toujours invoqué s’il est défini, même si un gestionnaire d’erreurs global est défini, de sorte que vos gestionnaires d’erreurs locaux existants s’exécuteront comme d’habitude. Le gestionnaire d’erreurs global n’est invoqué que si aucun gestionnaire d’erreurs local n’est défini dans le contexte d’exécution courant.
Fonctions ORDA et attributs calculés sur le serveur 4D
Comme vous le savez peut-être, lorsqu’une fonction ORDA ou un attribut calculé est utilisé dans une application client, il est exécuté du côté du serveur 4D. Ainsi, si ces fonctions ou attributs calculés ne définissent pas de gestionnaire d’erreur local et qu’ils génèrent des erreurs, la boîte de dialogue d’erreur intégrée de 4D s’affiche sur le serveur 4D lorsqu’il n’est pas exécuté en mode headless.
Pour éviter cela, vous pouvez maintenant définir un gestionnaire d’erreur global côté serveur dans la méthode de base de données On Server Startup, par exemple :
ON ERR CALL("myServerGlobalErrorHandler"; ek global)Composants
En tant que développeur de composants, il est désormais plus facile pour vous de gérer les erreurs. Il vous suffit de définir votre gestionnaire d’erreur global dans la méthode de base de données On Host Database Event (par exemple, dans l’événement On before host database startup ) pour vous assurer qu’aucune erreur n’affichera la boîte de dialogue d’erreur intégrée de 4D dans la base de données hôte ! De cette façon, toutes les erreurs générées par le composant appelleront le gestionnaire d’erreurs global du composant sans aucun effet secondaire sur la base de données hôte.
En tant qu’utilisateur de composant, vous pouvez rendre votre application plus sûre en traitant les erreurs de composant qui n’ont pas été interceptées dans le contexte d’exécution du composant. De cette façon, si vous utilisez des composants qui ne gèrent pas correctement leurs propres erreurs, vous pouvez les gérer, et plus aucun dialogue d’erreur intégré 4D n’apparaîtra. Pour installer une méthode de gestion des erreurs d’un composant, il suffit d’utiliser le paramètre correspondant comme ceci :
ON ERR CALL("myComponentErrorHandler"; ek errors from components)Il s’agit également d’un gestionnaire d’erreurs global mais dédié aux erreurs non capturées par les composants afin que vous puissiez développer du code spécifique pour celles-ci. Notez que les variables système d’erreur (error, error method, error line, et error formula) ne sont pas disponibles dans ce gestionnaire d’erreur de composant car les erreurs proviennent d’un autre contexte d’exécution. Mais la pile d’erreurs est toujours disponible.
COMPORTEMENTS COMMUNS
Pile d’erreurs
Nous avons également introduit une nouvelle commande pour obtenir la pile d’erreurs complète : Last errors. Cette commande retourne une collection où chaque élément est une erreur de la pile, chacune contenant des informations sur le numéro d’erreur, le message et la signature du composant interne.
Récupérer le gestionnaire d’erreurs courant
La commande Method called on the error admet maintenant un paramètre optionnel pour récupérer le gestionnaire d’erreurs global et le gestionnaire d’erreurs du composant, comme dans cet exemple :
$localHandler:=Method called on error
$globalHandler:=Method called on error(ek global)
$componentHandler:=Method called on error(ek errors from component)Abandon de l’erreur
Quel que soit le gestionnaire exécuté, la commande ABORT est toujours efficace et vous permet d’interrompre l’exécution du code comme d’habitude.
Vous pouvez tester tous ces nouveaux comportements avec le HDI ci-dessus.