Journalisation et gestion des erreurs pour un debugage efficace.

Posted on 05/04/2008 · Posted in Programmation

Voyons les étapes de vie d'un programme; de sa conception, à son utilisation régulière par l'utilisateur final.

Les quatre étapes majeures sont :
– Réflexion, modélisation des données.
– Réalisation, développement principal.
Recette, utilisation par une poignée d'utilisateur pour faire les premiers tests en situation finale.
Mise en production, où le programme est disponible chez l'utilisateur final.

Au cours des premières étapes il peut être judicieux de mettre en place différents systèmes, qui permettront de réagir de manière efficace, et rapide face aux problèmes.

– Lorsque l'on programme, on peut rencontrer des erreurs, les plus simples à corriger étant les erreurs de compilation, alors que les erreurs à l'exécution peuvent parfois être un vrai calvaire à corriger.

– Lors de la mise en production, le client peut appeler en hurlant “Nous avons une erreur critique, nous devons bloquer une partie de notre activité tant que vous n'avez pas résolut cela !”, et c'est dans ces moments là qu'il faut réagir très vite.

Une personne à dit “Aide toi, et le ciel t'aidera”, même si cette personne n'était pas un développeur – informatique – son message est important. En effet, pour pouvoir être efficace à corriger des problèmes, il faut savoir les cibler, et si vous n'avez rien mis en place, personne ne pourra vous dire vraiment où se trouvent les erreurs.
Et puis d'ailleurs, pourquoi votre client devrai bloquer son activité à cause de vous ? Même si aucune application ne peut être parfaite, aucune ne devrait bloquer complètement suite à une erreur – sauf windows.

Nous allons donc traiter de manière générale la gestion des erreurs, et la journalisation, pour aboutir au final sur une prise de conscience des bonnes pratiques de programmation qui tendent vers une correction de bug efficace.

La gestion des erreurs
Pourquoi gérer les erreurs ?
Simplement parce que certaines erreurs peuvent être fatales et empêcher l'utilisation du programme, pire l'utilisateur peut être confronté à des réactions complètement imprévues…
Dans la majorité des langages de hauts niveau, on peut trouver les instructions “try/catch/finally”, comprenez ici “essayer/attraper/finalement”.
En gros, on essaye un bout de code avec “try”, si ça se passe bien, on continu comme si de rien n'était. S'il y a un problème, on va voir dans “catch” si on peut faire quelque chose et réagir en gentleman. Finalement on effectue le code contenu dans “finally” quoi qu'il arrive, erreur ou pas.

Voyons un exemple concret en AS 3.
Ce langage possède quelques restrictions, comme son incapacité à vérifier l'existence de fichier ou à lister le contenu d'un répertoire. Donc quand on veut charger un fichier, on doit faire confiance à la personne qui spécifie le chemin de chargement.
Si le fichier existe, aucun soucis, mais dans le cas contraire… l'utilisateur aura de jolies lignes d'erreur qui s'afficheront dans une fenêtre ouverte par Flash Player.

Comment charger un fichier :

var request:URLRequest = new URLRequest("urlLoaderExample.txt");
loader.load(request);

Maintenant, on va ajouter le gestionnaire d'erreur

try
{
  loader.load(request);
}
catch (error:Error)
{
  trace("Impossible de charger le fichier.");
}

Notre “catch” récupère tout type d'erreur apparut dans le try.
Il faut savoir que la méthode load de la class URLLoader peut diffuser plusieurs type d'exception.

try
{
  loader.load(request);
}
catch (error:SecurityError)
{
  trace("Probleme de sécurité");
}
catch (error:TypeError)
{
  trace("L'url est null.");
}
catch (error:Error)
{
  trace("Impossible de charger le fichier.");
}

Mais nous pouvons aussi avoir plusieurs fonctions à la suite susceptibles de diffuser des exceptions, il faut donc pouvoir toutes les attraper. Dans ce cas, vous pouvez mettre plusieurs fonctions retournant des exceptions dans un bloc “try”, ou en avoir plusieurs pour chaque fonctions.

A vous de réagir en fonction des exceptions diffusées.
Pour cela, il faut bien lire les documentations des langages, et les exceptions qui peuvent être levées.
Donc tenez-vous informer des fonctions que vous utilisez, les documentations des API sont souvent très complètes.

La journalisation
Dixit Wikipédia “La journalisation (en anglais logging) est l'action de relever dans un journal (en anglais log) tous les évènements qui se produisent dans un système informatique pendant son fonctionnement.”
En quoi cela peut nous aider ?
Tout simplement à savoir quand s'est produit un bug. En effet, quand vous qui découvrez un problème, vous savez à peu prés ce que vous avez effectué. Mais quand il s'agit d'une personne qui vous appelle pour vous signaler un bug, et que vous n'arrivez pas à le reproduire… Vous allez en passer du temps à dénicher le petit bug.

Après, c'est à vous de réfléchir sur la méthode à mettre en place. En fonction de l'application, et surtout du niveau de journalisation que l'on souhaite appliquer, vous serez amené à conserver uniquement les actions utilisateurs, système, environnemental, et même l'ensemble de toutes ces composantes.

En exemple une application Flash développer en AS3. Il s'agit d'une plate forme multimédia capable de lire une play liste XML, et de réagir à des actions utilisateurs comme “Suivant/Précédant”…
Le problème de cette technologie est lié à la sécurité, en effet il est impossible d'écrire sur le disque dur. Donc l'envoi de fichier LOG ne sera pas possible.
Nous avons opté pour l'affichage d'un Hash contenant les actions effectuées. L'utilisateur en cas de problème, devra nous envoyer un mail en ayant copie ce Hash.

Pour des technologies où il est possible de générer des fichiers, je vous conseille fortement de les utiliser et de les remplir en utilisant les retours à la ligne. Chaque ligne étant composé d'un numéro unique et d'une bref description correspondant à l'évènement.
Exemple

[00-1023] #Description de l'action

Pour quel type d'application utiliser la gestion des erreurs, la journalisation
Lorsqu'il s'agit d'application dont vous aurez à faire un suivi technique.
En effet, personne ne peut produire un code exempt de bug, et cette idée croit en fonction de la taille de l'application que vous créez et du nombre de personne à travailler sur son développement.
De plus, cela est une preuve de la qualité du code que vous produisez.