Aides à la compilation

 Les aides à l’analyse et à la correction des bases sont de trois types :

• l’aide à l’analyse proprement dite est fournie par le fichier de symboles. Cette table vous permettra de vous repérer plus rapidement dans vos variables. C’est un outil précieux d’interprétation des erreurs délivrées par le compilateur.
• l’aide à la correction est fournie par le fichier d’erreurs que vous pouvez utiliser comme fichier texte.
• l’aide à l’exécution ou contrôle d’exécution vous fournit un outil supplémentaire de contrôle de cohérence et de fiabilité de vos applications.

Note : Une aide non négligeable est également fournie pour le typage des variables par les méthodes compilateur automatiques — cf. paragraphe Générer typage.

Le fichier de symboles est un document de type texte, plus ou moins long suivant l’importance de vos bases. Par défaut, ce fichier n’est pas généré au moment de la compilation. Vous devez cocher l’option correspondante dans les Propriétés de la base (cf. paragraphe Options de compilation). Lorsqu’il est généré, le fichier est placé dans le dossier contenant la structure de la base et est automatiquement nommé NomDeLaBase_symbols.txt. 

Le fichier de symboles se présente ainsi lorsque vous l’ouvrez à l’aide d’un éditeur de texte :

L’en-tête présente le nom de la base, la date et l’heure de la création du document. Le document se compose de quatre parties :

• la liste des variables interprocess.
• la liste des variables process.
• la liste des variables locales dans leur méthode.
• la liste complète des méthodes projet et des méthodes base avec leurs paramètres, le cas échéant.

Ces deux listes sont séparées en quatre colonnes par des tabulations :

• la première contient la liste complète des variables process et interprocess utilisées dans votre base. Ces variables sont rangées par ordre alphabétique.
• la deuxième affiche le type de la variable. Ce type a été déterminé par une directive de compilation, sinon il est déduit par le compilateur en fonction de l’utilisation de la variable. Si le type d’une variable n’a pu être déterminé, cette colonne reste vide.
• la troisième colonne contient le nombre de dimensions du tableau, lorsque la variable est un tableau.
• la quatrième colonne comporte la référence au contexte dans lequel le compilateur a trouvé le type de la variable. Si la variable est utilisée dans plusieurs contextes, seul le contexte qui a permis au compilateur de déterminer son type est mentionné.
  
  • Si la variable est trouvée dans une méthode base, son nom est inscrit comme il a été défini dans 4D, précédé de (M)*.
  • Si la variable est trouvée dans une méthode projet, son nom est inscrit comme il a été défini dans 4D, précédé de (M).
  • Si la variable est trouvée dans un trigger (méthode table), c’est le nom de la table qui est inscrit, précédé de (MT).
  • Si la variable est trouvée dans une méthode formulaire, le nom du formulaire est inscrit, précédé du nom de la table et de (MF).
  • Si la variable est trouvée dans une méthode objet, le nom de la méthode objet est inscrit précédé du nom du formulaire, du nom de la table et de la mention (MO).
  • Si la variable est un objet d’un formulaire, sans intervenir dans une quelconque méthode projet, méthode formulaire, trigger ou méthode objet, le nom du formulaire dans lequel elle apparaît est inscrit, précédé de la mention (F).
  En fin de liste, vous trouvez la taille des variables process et interprocess en octets.

Note : Dans le cas des variables process, au moment de la compilation, le compilateur ne peut déterminer dans quel process une variable de ce type est utilisée. En effet, une variable process peut avoir une valeur différente dans chaque process.Toutes les variables process sont donc systématiquement dupliquées à chaque création de process : il convient de prendre garde à la taille mémoire qu’elles vont occuper. La taille des variables process est totalement indépendante de celle de la pile des process.

La liste des variables locales apparaît classée par méthode base, méthode projet, trigger, méthode formulaire et méthode objet en suivant le même ordre que dans 4D.

Cette liste est séparée en trois colonnes par des tabulations :

• la première contient la liste des variables locales utilisées dans la méthode ;
• la deuxième affiche le type de la variable ;
• la troisième contient le nombre de dimensions du tableau, lorsque la variable est un tableau.

A la fin du fichier sont réunies toutes vos méthodes base et projet avec :

• leur type (procédure ou fonction retournant une valeur)
• éventuellement le type de leurs paramètres et du résultat renvoyé
• le nombre d'appels,
• la propriété Thread Safe ou Thread Unsafe (cf. Process 4D préemptifs)

Ces informations apparaissent sous la forme suivante :

Vous pouvez générer ou non un fichier d’erreurs lors de la compilation grâce une option située dans les Propriétés de la base (cf. paragraphe Options de compilation). Lorsqu’il est généré, le fichier d’erreurs est nommé NomDeLaBase_errors.xml et est créé à côté du fichier de structure de la base.

Bien que les erreurs soient directement accessibles via la fenêtre de compilation, dans le cadre d’un développement en client/serveur, il peut être intéressant de disposer d’un fichier d’erreurs qu’il est alors possible de transmettre d’un poste à l’autre. Le fichier d’erreurs est généré au format XML afin de faciliter l’analyse automatique de son contenu. Il autorise également la création d’interfaces personnalisées de présentation des erreurs.

Le fichier d’erreurs est plus ou moins long suivant le nombre d’erreurs et de warnings délivrés par le compilateur. Il se présente ainsi lorsque vous l’ouvrez avec un éditeur de texte :

Ce fichier d’erreurs est structuré ainsi :

• en tête de ce fichier se trouve la liste des erreurs et warnings, regroupés par méthode et cela dans le même ordre que celui que vous avez observé dans 4D ;
• sous la rubrique ***Erreurs générales*** sont regroupées toutes les impossibilités de typage et les ambiguïtés d’identité. Ces indications sont détaillées de la façon suivante :
  
  • en premier lieu, le numéro de ligne dans la méthode (le numéro 0 est retourné pour les erreurs générales) ;
  • en second lieu, l’attribut warning indique si l’anomalie détectée est un warning (warning="true") ou une erreur (warning="false") ;
  • en troisième lieu, un diagnostic sur la nature de l’erreur.
  Si votre base ne présente aucune erreur générale, le fichier ne comporte pas de section “Erreurs générales”.

Un fichier d’erreurs peut donc comporter trois types de messages :

• les erreurs attachées à une ligne précise,
• les erreurs générales,
• les warnings.

Ces erreurs, de différentes natures, vous sont indiquées accompagnées de leur contexte, de la ligne où elles ont été détectées et d’un commentaire. Elles apparaissent lorsque le compilateur rencontre une expression qui lui pose un problème, que ce soit de typage ou de syntaxe.

Dans la fenêtre de compilation, il vous suffit de double-cliquer sur le libellé de l’erreur pour ouvrir la méthode concernée à la ligne correspondante.

La liste des diagnostics d’erreurs de syntaxe/de typage est fournie dans la section Messages d'erreurs du manuel Langage de 4D.

Il s’agit d’erreurs qui ne permettent pas le passage en passe de compilation. Le compilateur délivre une erreur générale dans deux cas :

• si le type d’une variable process ou interprocess n’a pas pu être déterminé.
• si deux objets de nature différente portent le même nom.

Ces erreurs sont dites générales parce qu’elles ne peuvent être rattachées à aucune méthode en particulier. En effet, le compilateur n’a pu procéder au typage nulle part dans la base pour le premier cas, et, dans le second, il ne peut choisir d’associer un nom à un objet plutôt qu’à un autre.

La liste des erreurs générales est fournie dans la section Messages d'erreurs du manuel Langage de 4D.

Les warnings ne sont pas des erreurs. Ils n’empêchent pas la compilation de la base. Il s’agit simplement de points sur lesquels le compilateur souhaite attirer votre attention parce qu’il y a un risque d’erreur.

Dans la fenêtre de compilation, les warnings apparaissent en caractères italiques. Il vous suffit de double-cliquer sur le libellé d’un warning pour ouvrir la méthode concernée à la ligne correspondante. La liste des warnings est fournie dans le paragraphe Les warnings du manuel Langage de 4D.

Il est possible de désactiver certains warnings (cf. paragraphe Désactivation des Warnings durant la compilation).

Le contrôle d’exécution est coché par défaut dans les Propriétés de la base (cf. paragraphe Options de compilation). 

Alors que toute les autres options fonctionnent durant le processus de compilation, le contrôle d’exécution fonctionne lorsque vous lancez une base compilée. C’est donc en cours d’exécution de votre application que vous recevrez les messages délivrés par le compilateur.

Le contrôle d’exécution introduit une analyse supplémentaire par rapport à la recherche de cohérence logique et syntaxique qui caractérise normalement un compilateur. Dans le contrôle d’exécution, le compilateur introduit pour vous la question suivante : “compte tenu de ce que vous m’avez demandé, j’arriverai probablement à un résultat qui peut vous surprendre”. Le contrôle d’exécution est un contrôle en situation, dépendant de l’état des objets de la base à un instant donné.

Imaginez, par exemple, que dans votre base, vous déclariez un tableau LeTableau de type Texte. Suivant la méthode en cours d’exécution, le nombre d’éléments de LeTableau peut varier. Vous souhaitez affecter à l’élément 5 du tableau la valeur “Bonjour”. Vous écrivez donc :

Si, à ce moment-là, LeTableau comporte 5 éléments ou plus, tout va bien. L’affectation s’effectue normalement. Il y a bien un élément numéro 5, prêt à recevoir cette valeur. Si, pour une raison ou pour une autre, à ce moment précis de l’exécution, LeTableau comporte moins de 5 éléments, 2 par exemple, votre affectation n’a plus de sens. 

Il est évident que ce type de situation ne peut être détecté à la compilation puisqu’il présuppose l’exécution des méthodes. Seul le contrôle d’exécution vous permet d’avoir la maîtrise de ce qui se passe effectivement lorsqu’on utilise la base. Dans l’exemple évoqué ci-dessus, le compilateur vous délivrera donc, dans 4D, une erreur d’exécution. On comprend dès lors que le contrôle d’exécution soit particulièrement précieux dans le cas de manipulations sur les tableaux, les pointeurs et les chaînes de caractères.

Les messages type délivrés par le compilateur lorsque vous demandez le contrôle d’exécution sont listés dans le paragraphe Les messages du contrôle d’exécution du manuel Langage de 4D.

Dans certains cas, vous pouvez souhaiter que, bien que le contrôle d’exécution soit activé, il ne s’applique pas sur des parties fiabilisées du code. En effet, notamment dans le cas de boucles répétées de nombreuses fois et lors de l’exécution de la base compilée sur des machines anciennes, ce contrôle peut ralentir sensiblement les traitements. Dans la mesure où vous avez la certitude que le code en question est fiable et ne peut provoquer d’erreur système, vous pouvez désactiver localement le contrôle d’exécution.

Pour cela, vous devez encadrer le code à exclure du contrôle d’exécution avec les commentaires spéciaux //%R- et //%R+. Le commentaire //%R- désactive le contrôle d’exécution et //%R+ le réactive :

Note : Ce mécanisme ne fonctionne que si le contrôle d’exécution est activé.

Vous notez des anomalies de fonctionnement dans vos bases ? Avant toute spéculation sur leur origine, pensez aux aides fournies par le compilateur. 

Les anomalies que vous pouvez avoir sont les suivantes :

• 4D fait apparaître ses propres messages d’erreurs et vous n’en voulez pas.
  Corrigez cette erreur dans votre application d’après l’indication fournie par 4D. Si cette indication vous semble trop générale, recompilez votre base en vous assurant que le contrôle d’exécution est sélectionné. Testez à nouveau votre base : à l’endroit où apparaissait le message de 4D, vous aurez un message délivré par le compilateur.
• Votre base compilée ne fonctionne pas exactement comme votre base interprétée.
  Examinez d’un peu plus près les messages des Warnings.
• Les variables Numériques ou Alphanumériques ne présentent pas les valeurs que vous attendiez. Vérifiez les options de typage par défaut dans les Préférences et examinez le fichier de symboles pour vérifier que toutes vos variables sont bien typées comme vous le souhaitez.
• Votre base fonctionne normalement en mode interprété et, lorsque vous l’utilisez après la compilation, une erreur provoque un “plantage” de l’application. Assurez-vous de compiler avec l’option “Contrôle d’exécution”.
  Vérifiez également que votre base compilée dispose des mêmes plug-ins que ceux que vous avez utilisés au moment de la compilation.