Je vous propose une méthode de gestion des erreurs qui permet d’implémenter rapidement un debuggage efficace dans les programmes que vous devrez maintenir ou écrire.

La méthode que je vous propose permet de gagner du temps de développement et de debuggage, tout en luttant contre le syndrome “pas le temps, on le fera plus tard”.

Intérêt de la méthode proposée

Pour le traitement d’une erreur, nous avons besoin de générer 2 types d’informations :

  1. un message d’erreur compréhensible et utile pour l’utilisateur, afin de ne pas surcharger inutilement la hotline
  2. des informations techniques claires et détaillées pour nous aider à débusquer le bug : procédure dans laquelle l’erreur a été déclenchée, état des variables en cause, etc.

Ecrire le code de gestion des erreurs prend parfois plus de temps que d’écrire la fonctionnalité : la méthode que je vous propose m’a permis de gagner en productivité.
Résumé du mécanisme implémenté

Chaque procédure sera dotée d’une gestion des erreurs par défaut.

Nous souhaitons mettre en place un mécanisme qui évitera le plantage de l’application pour les bugs bénins (erreurs d’affichage, échec de connexion, etc.). Ce mécanisme affichera une boite de dialogue lorsque l’erreur nécessite une action de l’utilisateur ou s’il est nécessaire d’avertir l’utilisateur qu’une erreur est survenue. L’erreur sera également conservée dans un fichier log, car il est rare que les utilisateurs notent les messages affichés à l’écran : par contre, si l’utilisateur nous indique le moment où il a rencontré l’erreur, nous pourrons retrouver le message affiché et tous les renseignements nécessaires pour traiter le bug.
Ce mécanisme nous offrira la possibilité de cacher l’erreur à l’utilisateur, en l’inscrivant dans le fichier log sans afficher de boite de dialogue utilisateur.

Le module de gestion des erreurs

Nous allons donc dédier un module complet à la gestion des erreurs : chaque routine de gestion d’erreur se contentera d’appeler une procédure de ce module. Toutes les autres procédures de notre application seront dotées d’une routine simple de gestion d’erreur. Voici un exemple avec une gestion “en ligne” des erreurs (VB6, VBnet) :

on error goto erreur
(code)
erreur :
call GererErreurDonnees

La même chose dans une version plus structurée (VBnet, C#) :

try

(code)

catch

call GererErreurAffichage

finally

(code)

Cet exemple vous montre déjà que notre module spécialisé comporte une procédure pour chaque grand type d’erreur que nous identifions :

  • GererErreur : procédure générale pour toutes les erreurs pour lesquelles nous ne souhaitons pas écrit de procédure spécifique
  • GererErreurDonnees
  • GererErreurAffichage
  • GererErreurPortCom
  • (etc.)

Chacune de ces procédures recevra en argument :

  • numeroErreur (double) : le numéro d’erreur; un numéro d’erreur interne pourra être substitué à celui par visual basic
  • messageErreur (string) : on pourra substituer un message personnalisé au texte fourni par VB
  • subAppelante (string) : la procédure ou fonction appelante nous fournit son nom, ce qui sera souvent utile pour le debuggage
  • nePasAfficherBoiteDialogue (boolean) : par défaut on affiche la boîte de dialogue, donc cet argument pourra être optionnel, ce qui permettra de réduire le code à écrire pour appeler cette procédure
  • rajoutez tout élément nécessaire au debuggage. Pour ma part, je rajoute généralement ces éléments dans la procédure appelante, en les intégrant à la chaîne messageErreur.

Dans le code des procédures de ce module, nous réaliserons :

  1. optionnel : identification de l’erreur et construction d’un message compréhensible pour l’utilisateur, à partir des arguments fournis. Vous pouvez aussi intégrer des arguments supplémentaires pour construire votre chaîne.
  2. appel de la procédure AfficherErreur

La procédure AfficherErreur recevra en arguments :

  • titreErreur (string) : le titre affiché par la boîte de dialogue. Mes titres prennent pour forme : “Erreur N°1 : saisie erronnée”.
  • texteErreur (string) : quelque chose de compréhensible un béotien
  • nePasAfficherBoiteDialogue (boolean) : par défaut on affiche la boîte de dialogue
  • separateur (string) : une chaine de symboles placée au début et à la fin du texte inséré dans le fichier log. Cette chaîne vous permettra de distinguer les erreurs selon leur type dans le fichier log.
    Par exemple, toutes mes erreurs d’accès aux données utilisent une ligne de “#”.

Au lancement du logiciel, on devra initialiser comme variable locale de ce module une chaîne pour stocker le chemin d’accès au fichier log : cheminFichierLog. Le nom de fichier log pourra être une variable ou une constante : nomFichierLog.

Le code de la procédure AfficherErreur commencera par structure vérifiant l’état de nePasAfficherBoiteDialogue.
Si nécessaire on affichera la boîte de dialogue.

Ensuite et dans tous les cas, on écrira l’erreur dans le fichier log. En plus du titre et du texte de la boite de dialogue, n’oubliez pas de mémoriser la date de l’erreur.

Pour les test de votre logiciel, je vous propose une astuce pour gagner du temps : mettre en commentaire cette structure alternative, ce qui permet de visualiser systématiquement toutes les erreurs imprévues survenant dans le logiciel.