Exemple de diagnostic

La section précédente a démontré comment recueillir l’information requise à la production du diagnostic. Pour que le programmeur puisse utiliser cette information, le diagnostic doit être facile à comprendre et à interpréter. Cette section reprend la trace d’exécution produite à la section précédente et donne un exemple de diagnostic produit.

La représentation du diagnostic dépend naturellement du médium utilisé pour présenter celui-ci. Si l’outil d’analyse est intégré à un environnement de développement, il est fort possible que le diagnostic soit affiché dans une fenêtre et permette, à l’aide de liens, la navigation entre le diagnostic et le programme source original. Dans le cas d’un outil spécifique et indépendant d’un environnement de développement, le diagnostic peut prendre la forme d’un simple rapport. Dans ce dernier cas, il est important de permettre de retrouver facilement les instructions du programme original à partir du diagnostic.

Le diagnostic présenté dans cette section suppose que le diagnostic est produit indépendamment de l’environnement de développement. Il présente les instructions avec l’information de la trace d’exécution et la valeur des variables. La figure 5.6 donne un exemple d’un diagnostic pour le programme de la figure 5.5.

Dans la figure 5.6, chaque instruction de la trace d’exécution est imprimée avec son numéro de ligne. Sur les lignes précédant l’instruction, les variables utilisées par l’instruction sont affichées avec leur valeur. Sur les lignes suivant l’instruction, les variables modifiées par l’instruction sont affichées avec leur nouvelle valeur. Il faut remarquer que le diagnostic n’inclut pas toutes les variables du programme. Le programme exemple est très simple, il contient sept instructions et trois variables. Un vrai programme compte beaucoup plus d’instructions et de variables. Pour ne pas produire un rapport de diagnostic trop volumineux, il est important d’inclure de l’information pertinente qui permet au programmeur de bien analyser l’anomalie identifiée.

Une ligne de séparation est insérée entre chaque instruction pour bien délimiter les étapes de la trace d’exécution. La trace est présentée dans l’ordre d’exécution des instructions, et non pas l’ordre dans lequel la trace est construite, qui donnerait la trace à partir de l’instruction en erreur en reculant dans l’exécution du programme. Cette dernière méthode rend la consultation du diagnostic moins intuitive pour l'utilisateur.

Figure 5.6 Exemple de diagnostic avec valeur des variables.

Le diagnostic de la figure 5.6 peut être interprété comme suit. À l’instruction 7, un incident potentiel est détecté et le diagnostic d’erreur y est produit. La variable qui provoque l’anomalie fait partie du message d’erreur. Il s’agit de la variable « J ». La valeur de la variable « J » en entrée à l’instruction indique une valeur « ¨ » qui signifie qu’à ce point, il est possible que la variable ne soit pas définie. Donc, au moins un chemin d’exécution se rend à cette instruction alors que la variable « J » n’est pas définie. L’instruction précédente de la trace d’exécution est l’instruction 6. Après l’exécution de cette instruction, la variable « J » a effectivement la valeur « ¨ ». Cependant, la valeur de la variable « J » n’apparaît plus dans la trace d’exécution. Il n’est pas évident à ce point de savoir pourquoi l’erreur se produit. Il serait plus utile d’inclure dans le diagnostic à chaque étape de la trace d’exécution la variable en erreur même lorsque celle-ci n’est pas utilisée par une instruction. Ce diagnostic est illustré à la figure 5.7.

Figure 5.7 Exemple de diagnostic avec les valeurs de la variable en erreur

Comme l’indique la figure 5.7, la valeur de la variable « J » apparaît avant et après chacune des instructions de la trace d’exécution. Le diagnostic indique, à l’entrée de l’instruction 6, qu’au moment de fusionner les contextes de la portion « vrai » de l’instruction conditionnelle avec le contexte de la portion « faux » que la variable « J » n’est pas définie dans le contexte de la portion « vrai ». Cela indique que la variable « J » n’est pas initialisée lorsque la condition « X > 0 » est vrai.

La valeur « ¨ » signifie que deux contextes ont été fusionnés et qu’un de ces contextes contient une valeur pour la variable alors que l’autre contexte indique que la variable est indéfinie. Il est donc possible de déterminer, lors de la production du diagnostic, la condition qui amène à avoir deux contextes différents en ce point. Dans la figure 5.7 à l’instruction 6, les deux contextes sont fusionnés. Dans le contexte « faux », la variable

« J » est définie et elle ne l’est pas dans l’autre contexte. La branche « vrai » de l’instruction conditionnelle est exécutée lorsque la variable « X » est supérieure à zéro. Le diagnostic peut donc indiquer que la variable « J » est indéfinie à l’instruction 7 parce que la variable « X » a une valeur supérieure à zéro à l’instruction 2. Ce genre de diagnostic permet de donner un maximum d’information à l’utilisateur pour faciliter le travail de correction des défauts.

Il a été mentionné précédemment que, pour un programme volumineux, le diagnostic peut être assez long. Une caractéristique intéressante permettant de faciliter l’utilisation du diagnostic est de donner le contrôle au programmeur sur le niveau d’information fournie dans le diagnostic. Inclure la variable en erreur avec toutes les instructions de la trace d’exécution peut aider à la résolution du problème. L’outil devrait permettre au programmeur de spécifier une liste de variables qui devraient également être incluses ou omises des traces d’exécution pour permettre d’obtenir plus ou moins d’information et faciliter la localisation des erreurs.