3.4Gestion des erreurs & débogage
L'essentiel en 30 secondes
- Trois familles d'erreurs : compilation, exécution et fonctionnelle — cette dernière est la plus dangereuse car rien ne la signale.
- QUAND EXCEPTION intercepte une erreur d'exécution ; on teste aussi les retours HFSQL plutôt que de supposer qu'une écriture a réussi.
- Déboguer = reproduire, isoler, comprendre la cause réelle, corriger puis vérifier ; côté utilisateur, message clair et journalisation.
Mini-cas filé — Yacine sauve une commande malgré la coupure
Yacine enregistre une commande de matériel électrique quand le serveur HFSQL devient inaccessible. Sans précaution, l'application s'arrête brutalement et l'utilisateur perd sa saisie. Il encadre l'écriture dans QUAND EXCEPTION, teste le retour de la requête et affiche un message compréhensible : « Commande non enregistrée : serveur indisponible, vérifiez le réseau. » Le détail technique part dans le journal, pas à l'écran. Plus tard, un total faux apparaît sur certaines commandes : Yacine reproduit le cas avec les mêmes lignes, pose un point d'arrêt avant le calcul, avance en pas à pas et découvre une ligne sans prix. Il note le réflexe : intercepter, tester, journaliser, puis reproduire et isoler avant de corriger.
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 3.4.
1. Trois familles d'erreurs
Un code robuste ne suppose jamais que tout se passera bien. L'erreur de compilation est détectée avant l'exécution : faute de syntaxe, nom inconnu. L'erreur d'exécution survient pendant le fonctionnement : division par zéro, fichier absent, réseau coupé, droits insuffisants. L'erreur fonctionnelle est la plus dangereuse : le programme s'exécute mais le résultat est faux, et rien ne la signale. Un total erroné dans une facture de Yacine relève de cette famille.
2. Intercepter et tester
Le WLangage propose QUAND EXCEPTION pour intercepter une erreur d'exécution et reprendre la main au lieu de laisser l'application planter. Mais l'interception ne remplace pas la vérification : une écriture HFSQL peut échouer pour un doublon, une contrainte ou un verrou. Yacine teste les retours des fonctions, prévoit un comportement de repli et affiche un message compréhensible — jamais un code technique brut. Le détail part dans le journal pour le diagnostic.
3. Une méthode de débogage
Le débogueur intégré offre des points d'arrêt, l'exécution pas à pas, l'inspection des variables et la pile d'appels. La méthode compte autant que l'outil : reproduire le problème de façon fiable, isoler le périmètre, comprendre la cause réelle et non le symptôme, puis corriger et vérifier l'absence de régression. Un bug qu'on ne sait pas reproduire ne peut pas être corrigé avec certitude.
🔎 Exemple concret — 🔎 Exemple concret — Intercepter, journaliser, comprendre
Yacine sécurise l'enregistrement d'une commande puis traque un total faux :
QUAND EXCEPTION DANS
HExecuteRequete(Req_AjoutCommande)
SI HEnDehors(Req_AjoutCommande) ALORS
Erreur("La commande n'a pas pu etre enregistree.")
FIN
FAIRE
JournalAjoute("Erreur HFSQL commande", ErreurInfo())
Info("Serveur indisponible : reessayez ou contactez le support.")
FIN
// Debogage : point d'arret avant le calcul, puis pas a pas
nTotal = CalculeTotalLignes(TAB_Lignes)Lecture : l'utilisateur reçoit une action à faire, le journal garde le détail technique.
Leçon : le point d'arrêt et le pas à pas montrent où la valeur devient fausse.
Vocabulaire de la section
- Erreur d'exécution
- Erreur survenant pendant le fonctionnement : fichier absent, réseau coupé, division par zéro.
Exemple simple : La requête HFSQL de Yacine échoue car le serveur est indisponible.
Ce que ce n'est pas : une faute de syntaxe signalée avant l'exécution.
Réflexe : plante pendant l'action → erreur d'exécution.
- QUAND EXCEPTION
- Mécanisme du WLangage qui intercepte une erreur d'exécution pour la traiter proprement.
Exemple simple : Yacine l'utilise autour de l'écriture de la commande.
Ce que ce n'est pas : laisser l'application s'arrêter brutalement devant l'utilisateur.
Réflexe : reprendre la main → QUAND EXCEPTION.
- Erreur fonctionnelle
- Situation où le programme s'exécute correctement mais produit un résultat faux.
Exemple simple : Un total de facture est faux à cause d'une ligne sans prix.
Ce que ce n'est pas : une exception qui interrompt visiblement le traitement.
Réflexe : résultat faux sans plantage → erreur fonctionnelle.
- Point d'arrêt
- Marqueur posé dans le code pour suspendre l'exécution et inspecter l'état à cet endroit.
Exemple simple : Yacine le pose avant CalculeTotalLignes.
Ce que ce n'est pas : une simple trace affichée après la fin du traitement.
Réflexe : observer une zone suspecte → point d'arrêt.
- Journalisation
- Enregistrement des erreurs et événements techniques pour diagnostiquer après coup.
Exemple simple : Yacine consigne l'erreur HFSQL dans le journal sans l'afficher à l'écran.
Ce que ce n'est pas : un message technique brut montré directement à l'utilisateur.
Réflexe : diagnostiquer à distance → journaliser.
En pratique — En pratique — Rendre son code robuste et déboguer
- Encadrez les opérations risquées (fichier, réseau, conversion, calcul) et testez les retours HFSQL, comme Yacine.
- Posez un point d'arrêt avant la zone suspecte, avancez en pas à pas et inspectez les variables.
- Appliquez la méthode : reproduire, isoler, comprendre la cause réelle, corriger puis vérifier.
- Remplacez les messages techniques par un message compréhensible et journalisez le détail pour le diagnostic.
Script pas-à-pas — traquer un total faux comme Yacine (4 min)
1) Reproduisez le problème avec les mêmes données et les mêmes actions. 2) Posez un point d'arrêt avant le calcul suspect et avancez en pas à pas. 3) Inspectez les variables : repérez la ligne dont le prix est vide ou mal converti. 4) Corrigez la cause réelle, pas le symptôme. 5) Vérifiez le cas corrigé et l'absence de régression sur les autres commandes.
Gardez ce réflexe : un bug non reproductible ne peut pas être corrigé avec certitude.
Modèle copier-coller — la fiche erreurs & débogage de Yacine
Erreurs : compilation / execution / fonctionnelle (la plus dangereuse)
Intercepter: QUAND EXCEPTION + tester les retours HFSQL
Utilisateur: message comprehensible ; detail technique dans le journal
Methode : reproduire -> isoler -> comprendre -> corriger -> verifier
Outils : point d'arret, pas a pas, variables, pile d'appels, traceUn serveur injoignable
Yacine intercepte l'erreur, journalise et invite l'utilisateur à réessayer.
Un total faux
Yacine reproduit, isole la ligne sans prix et corrige la cause réelle.
Un message brut
Yacine remplace « Erreur 0x8004 » par un message clair et actionnable.
Un bug intermittent
Yacine cherche ce qui varie (volume, poste, droits) pour le reproduire de façon fiable.
✓ Bonnes pratiques
- Toujours tester les retours des opérations risquées.
- Reproduire avant de corriger.
- Afficher un message clair, journaliser le détail.
✗ Pièges fréquents
- Supposer qu'une écriture HFSQL a réussi.
- Corriger le symptôme sans la cause.
- Montrer un code technique brut à l'utilisateur.
Points clés à retenir
- Compilation, exécution et fonctionnelle : trois familles aux conséquences différentes.
- QUAND EXCEPTION intercepte ; les retours HFSQL se testent.
- Déboguer = reproduire, isoler, comprendre, corriger, vérifier.
- Message utilisateur compréhensible et journalisation du détail technique.
Défi 48h — appliquez demain
Comme Yacine, encadrez une opération risquée de votre application (écriture HFSQL, lecture de fichier, conversion) dans QUAND EXCEPTION, testez son retour et journalisez le détail. Affichez un message compréhensible. Puis prenez un bug réel : reproduisez-le, posez un point d'arrêt, avancez en pas à pas et notez en une phrase la cause réelle que vous avez trouvée.
- Je distingue erreur de compilation, d'exécution et fonctionnelle.
- Je sais intercepter une erreur et tester un retour HFSQL.
- J'applique une méthode de débogage en quatre étapes.
Questions fréquentes
Comment traiter une erreur sans faire planter l'application ?
En anticipant les opérations risquées : accès fichier, réseau, base de données, conversions. Encadrez-les avec QUAND EXCEPTION, testez les retours, prévoyez un comportement de repli et journalisez le détail technique. L'utilisateur doit recevoir un message compréhensible et actionnable, jamais un code technique brut. Pour plusieurs écritures liées, une transaction évite un état incohérent.
Quelle est la meilleure méthode pour trouver l'origine d'un bug ?
Reproduire de façon fiable, isoler le périmètre, comprendre la cause réelle, puis corriger et vérifier l'absence de régression. Le débogueur — point d'arrêt, pas à pas, inspection des variables — appuie cette méthode, il ne la remplace pas. Un bug qu'on ne sait pas reproduire ne peut pas être corrigé avec certitude : commencez toujours par les conditions exactes.
À quoi sert le mécanisme QUAND EXCEPTION ?