Chapitre 5.4.11Les erreurs

Les bugs font partie du quotidien des développeurs. Comprendre comment ils se manifestent et comment on les identifie te permettra de mieux collaborer avec les équipes techniques quand quelque chose ne fonctionne pas.

Les types d'erreurs

Toutes les erreurs ne se valent pas. On les classe en grandes familles :

Les erreurs de syntaxe

C'est l'équivalent d'une faute de grammaire. Le programme refuse de se lancer parce qu'il ne comprend pas ce qu'on lui a écrit.

// Il manque la parenthèse fermante
if (age >= 18 {
    console.log("Majeur")
}
// SyntaxError: Unexpected token '{'

Ce sont les erreurs les plus faciles à corriger. L'éditeur de code les souligne en rouge avant même qu'on exécute le programme, et le message dit exactement où se trouve le problème.

Les erreurs d'exécution

Le code est bien écrit, mais quelque chose se passe mal au moment où il tourne. C'est comme une recette de cuisine correctement rédigée, mais tu te rends compte en la suivant qu'il te manque un ingrédient.

let client = null
console.log(client.email)
// TypeError: Cannot read properties of null (reading 'email')

Ici, on essaie de lire l'email d'un client qui n'existe pas (null). Le programme plante avec un message d'erreur. C'est le type d'erreur le plus courant dans le développement web.

Les erreurs de logique

Les plus vicieuses. Le programme tourne sans planter, mais il fait la mauvaise chose. Pas de message d'erreur, pas de crash, juste un résultat faux.

function calculerRemise(prix, pourcentage) {
    return prix + prix * pourcentage / 100  // + au lieu de -
}

console.log(calculerRemise(100, 20))  // 120 au lieu de 80

Le programme est content, il ne plante pas. Mais les clients paient plus cher au lieu de moins cher. Ce genre d'erreur peut passer inaperçu pendant des semaines si personne ne vérifie les résultats. C'est exactement ce que les tests automatisés, que nous verrons dans un prochain chapitre, servent à attraper, en vérifiant que le programme produit bien les valeurs attendues.

Le message d'erreur

Quand un programme plante, il produit un message d'erreur. Apprendre à le lire, c'est déjà la moitié du travail de débogage.

Un message d'erreur contient généralement :

• Le type d'erreur : TypeError, SyntaxError, ReferenceError... Le nom donne déjà un indice sur la nature du problème.
• La description : un texte en anglais qui explique ce qui s'est passé. Par exemple, "Cannot read properties of null" signifie qu'on a essayé d'accéder à quelque chose sur une variable vide.
• L'emplacement : le fichier et le numéro de ligne où l'erreur s'est produite.

TypeError: Cannot read properties of null (reading 'email')
    at envoyerConfirmation (commandes.js:42)
    at traiterCommande (commandes.js:18)
    at main (index.js:7)

La stack trace

Les lignes qui suivent le message d'erreur forment ce qu'on appelle la "stack trace" (trace de la pile d'exécution). C'est le chemin que le programme a suivi jusqu'au moment du crash.

Dans l'exemple ci-dessus, on lit de bas en haut : le programme a démarré dans main (fichier index.js, ligne 7), qui a appelé traiterCommande (commandes.js, ligne 18), qui a appelé envoyerConfirmation (commandes.js, ligne 42), et c'est là que ça a planté.

C'est exactement comme remonter le fil d'un accident, "la voiture a freiné parce que le feu est passé au rouge parce qu'il y avait un piéton sur le passage". La stack trace raconte l'histoire en sens inverse.

Quand tu signales un bug à un développeur, le plus utile que tu puisses lui donner, c'est le message d'erreur complet avec la stack trace. Une capture d'écran qui montre juste "une erreur s'est produite" sans le détail, ça oblige le développeur à reproduire le problème de son côté, ce qui peut prendre des heures.

Les erreurs silencieuses

Certaines erreurs ne font pas planter le programme. Elles passent inaperçues et causent des comportements étranges, une page qui affiche des données vides, un calcul qui retourne un résultat bizarre, un email qui ne part jamais.

C'est souvent le résultat d'une mauvaise gestion de l'absence de valeur. On a vu dans le chapitre sur les variables que null et undefined représentent le vide. Quand le code ne prévoit pas ces cas, il ne plante pas toujours. Il continue avec des données manquantes et produit un résultat incomplet ou faux.

Quand tu croises une erreur

La prochaine fois qu'un collègue ou un utilisateur te montre une erreur, tu sauras maintenant la décrypter. Cherche le type d'erreur et la description, ils te disent ce qui s'est passé. Regarde la stack trace, elle te dit où ça s'est passé. Et même si tu ne comprends pas tout, tu peux transmettre ces informations à un développeur, ce qui lui fera gagner un temps précieux.

La fin du commencement

C'est la fin de cette initiation à la programmation. Tu as maintenant tous les outils de base pour comprendre comment un développeur pense et structure son travail : des variables pour stocker, des types pour cadrer, des conditions pour décider, des boucles pour répéter, des fonctions pour organiser, la récursivité pour les structures imbriquées, des objets pour modéliser, des patterns pour ne pas réinventer la roue, et la capacité de lire du code comme de comprendre une erreur.

Si l'envie te prend d'aller plus loin, ouvre la console de ton navigateur et amuse-toi. La programmation, c'est avant tout de la logique et de la curiosité.