|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Après avoir réalisé quelques pas guidés en ARexx, il va falloir maintenant écrire soi-même ses programmes. Habituellement, cela ne va pas sans quelques erreurs... Même le programmeur le plus chevronné sait combien il est difficile et nécessaire de traquer les erreurs diverses nommées "bogues" partout dans le monde informatique ! Heureusement, conscient par expérience de ces difficultés, le père d'ARexx a fourni à l'interpréteur du langage un environnement de déverminage tout à fait efficace. Défauts La liste des défauts possibles est aussi immense que l'ingéniosité du programmeur, et il serait vain d'en tenter une revue exhaustive. Cependant, le seul type contre lequel on ne peut rien est le défaut de logique dans la réalisation. On peut alors déterminer les grandes classes de défauts et donner les méthodes pour leur détection et correction, soit par ordre de gravité : la faute d'orthographe, la faute de syntaxe et la faute de système. Faute d'orthographe Cette faute apparaît sous deux formes : orthographe des mots réservés par le langage et orthographe d'une variable, non constante. Dans le premier cas, l'analyseur orthographique du langage peut, mais pas toujours, détecter l'erreur. Dans le deuxième cas, l'analyseur orthographique est impuissant puisqu'il s'agit de noms de variables donnés par l'utilisateur, qui ne lui sont donc pas connus. Il faut se rappeler que l'analyseur orthographique n'est pas tout puissant et qu'il ne sait détecter au mieux que l'endroit où il ne comprend plus le programme, endroit qui est fréquemment différent de celui où se situe réellement la faute. Il peut donc indiquer une faute qui n'est pas la bonne. Un travail d'interprétation est parfois nécessaire. Faute de syntaxe Cette faute traduit la mauvaise écriture d'une instruction : boucle non fermée, mauvais emploi (au sens de l'usage) de ses paramètres, etc. Elle peut être localisée ou répartie si elle est placée à cheval sur un sous-programme. L'analyseur de syntaxe du langage trouve certaines erreurs mais seulement lorsqu'il ne comprend plus, si bien que l'indication de l'endroit et de l'erreur peuvent être erronés, indépendamment. Fréquemment, la détection d'une erreur est la seule chose que l'analyseur peut faire, il faut alors un travail de recherche en aveugle pour effectuer la correction. Faute de système Dans cette rubrique, on place toutes les fautes non couvertes par les définitions précédentes. La multitude se refuse à toute description. Moyens disponibles Plusieurs moyens sont disponibles en ARexx et peuvent être employés concurremment. Analyseur orthographique et syntaxique Il est toujours présent et fonctionne à chaque mise en oeuvre d'un programme (la rançon est le ralentissement de l'exécution dudit programme). Un catalogue de 48 messages est donné ; certains sont très explicites, comme le numéro 3 (mémoire insuffisante), d'autres le sont moins, comme le numéro 34 (caractère étranger) qui ne précise rien et qui peut avoir rapport à un caractère non ASCII, donc invisible à l'écran. A chaque message est associée une sévérité qui permettra par la suite d'effectuer une recherche sélective en fonction du niveau de sévérité. Dans tous les cas, l'erreur provoque l'arrêt de l'exécution et l'affichage de la raison supposée. Une analyse est effectuée avant exécution du programme et certaines erreurs, comme le manque d'apostrophes (quotes) sont signalées dès le début ; d'autres ne sont signalées qu'à la découverte. Écriture du résultat Dans la forme la plus simple, le résultat de la détection d'erreurs est affiché dans la fenêtre en cours. Cette disposition mélange le résultat du programme et celui de la détection d'erreurs, ce qui peut être désagréable à divers points de vue. Il peut être préférable d'utiliser une fenêtre séparée. C'est le rôle du petit programme nommé "tco" et distribué avec ARexx. "tco" signifie "Tracing Console Open". Ce programme doit être lancé en premier. Il ouvre une console spécifique dans laquelle on verra défiler les erreurs éventuelles. Pour le quitter, on utilise "tcc" (Tracing Console Close). Ces commandes doivent figurer dans le répertoire C:. Cette forme de détection d'erreurs implicite, si l'on peut dire, permet de trouver les erreurs grossières mais devient rapidement hors de propos lorsque les défauts sont plus subtils. La fonction TRACE Cette instruction qu'on inscrit dans le programme suit son déroulement et en fait un rapport instruction par instruction. Le "traçage" peut être paramétré pour ne s'intéresser qu'à certains éléments du programme. Il n'est pas non plus nécessaire de tracer tout le programme. Une instruction d'arrêt du traçage permet de contrôler précisément la portion de programme à tracer. La forme est donc :
Si tco a été lancé, le résultat de la trace est écrit dans cette console. L'instruction TRACE s'écrit :
1. Pour XXX égale ALL : trace de toutes les instructions. Cela permet de voir comment se déroule le programme.
2. Pour XXX égale COMMANDS : seules les commandes vers l'extérieur sont tracées.
3. Pour XXX égale ERRORS : l'erreur provoquée était ligne 7 : a=test(z), "z" étant une variable nouvelle sans valeur attribuée.
La variable étant non initialisée, l'appel du sous-programme s'effectue mal, d'où l'erreur en ligne 7. En ligne 14, l'opération n'a donc pas pu se faire. Les "+++" en tête de ligne indiquent une erreur de syntaxe ou de commande. 4. Pour XXX égale INTERMEDIATES : c'est la forme la plus complète, dans laquelle toutes les valeurs intermédiaires sont tracées. Plusieurs sigles sont utilisés, dont voici la signification :
L'appel au sous-programme a été fait dans une boucle à deux passes, il y a deux fois appel à ce sous-programme. 6. Pour XXX égale NORMAL : ce mode ne trace que les erreurs qui sont d'une sévérité supérieure à un niveau préétabli ; in verra comment après. 7. Pour XXX égale RESULTS : ce mode n'affiche que les résultats.
Exploitation des résultats L'endroit où les résultats sont affichés dépend du choix qui a été effectué au préalable. Si rien de particulier n'a été décidé, tout se passe sur la console standard. Si tco a été lancé, seules les opérations de traçage apparaissent dans la fenêtre ou console spécialisée. Cependant, les dimensions de l'écran étant limitées et l'exécution pouvant concerner un grand nombre de lignes, il est possible qu'on ne puisse pas examiner à loisir tout le traçage. Tout au plus peut-on arrêter momentanément le défilement avec le bouton droit de la souris, mais cela ne permet pas d'aller et venir pour traquer le défaut. Il est possible, moyennant une ligne de programme supplémentaire, de diriger le flux qui apparaît sur la console tco vers le support le plus intéressant : imprimante, fichier en RAM: ou sur disque, etc. A partir d'un fichier, n'importe quel traitement de texte ou même l'éditeur dont on se sert pour écrire le programme permet l'édition du fichier de traçage et par là même, son analyse à loisir. L'instruction miracle qui peut être placée dans le programme avant l'instruction trace s'écrit :
Où "zzz" égale PRT: pour l'imprimante, ou RAM:test pour un fichier test en RAM:, ou encore DH0:test/essai pour un fichier essai dans le répertoire test du disque dur DH0:. On notera cependant que STDERR n'a pas de possibilité d'être ouvert vers plusieurs sorties simultanées. Pour terminer à l'endroit où l'on veut, on insérera l'instruction :
Ce qui permet d'effectuer un traçage localisé si besoin est. Dans l'article suivant, nous verrons la fin des possibilités de déverminage telles que les points d'arrêt, les commandes te, signal, le code de retour (return code : RC), le déverminage interactif, ou encore le transfert en cas d'erreur comme partie du programme.
|