Comment lire et comprendre une stack trace d'erreur

Qu'est-ce qu'une 'stack trace' et pourquoi est-elle votre meilleure alliée ?

Vous avez sûrement déjà vu ce grand bloc de texte rouge apparaître dans votre terminal après l'échec d'un script. Votre premier réflexe est peut-être de vous sentir frustré ou intimidé. Pourtant, cette 'stack trace' (ou 'trace de la pile d'exécution') est l'outil de diagnostic le plus puissant à votre disposition. Elle n'est pas là pour vous punir, mais pour vous guider.

Imaginez-la comme la boîte noire d'un avion. Elle enregistre la séquence exacte des événements qui ont mené à l'incident. Chaque ligne est une étape du voyage de votre programme. En apprenant à la lire, vous transformez un message d'erreur cryptique en une feuille de route claire qui vous mène directement à la source du problème. C'est la compétence fondamentale qui sépare un développeur qui subit les bugs de celui qui les maîtrise.

Anatomie d'une stack trace : décomposer un exemple simple

Pour comprendre comment cela fonctionne, créons volontairement une erreur. Imaginons un fichier calculator.rb avec le code suivant, qui tente de diviser un nombre par zéro, ce qui est mathématiquement impossible.

def divide(a, b)
  a / b
end

def calculate
  result = divide(10, 0)
  puts result
end

calculate

En exécutant ce fichier avec ruby calculator.rb, vous obtiendrez une sortie qui ressemble à ceci :

Traceback (most recent call last):
        2: from calculator.rb:9:in `<main>'
        1: from calculator.rb:5:in `calculate'
calculator.rb:2:in `/': divided by 0 (ZeroDivisionError)

Ce n'est pas aussi effrayant qu'il y paraît. Décortiquons les trois parties essentielles, en lisant de bas en haut :

• La ligne du bas (la plus importante) : calculator.rb:2:in `/': divided by 0 (ZeroDivisionError). Elle vous donne tout : le fichier (calculator.rb), le numéro de la ligne (2), la méthode ou l'opération (/), le message d'erreur explicite ('divided by 0') et le type d'erreur (ZeroDivisionError). C'est ici que l'erreur s'est produite.
• La ligne du milieu : 1: from calculator.rb:5:in `calculate'. Elle nous dit que la ligne fautive (ligne 2) a été appelée depuis la ligne 5, à l'intérieur de la méthode calculate.
• La première ligne : 2: from calculator.rb:9:in `<main>'. Elle nous informe que la méthode calculate a elle-même été appelée depuis la ligne 9, dans le contexte principal du script.

Vous voyez ? La stack trace est simplement l'historique des appels, le plus récent étant en bas dans ce format.

La méthode en 3 étapes pour lire n'importe quelle stack trace

Face à une erreur, au lieu de paniquer, suivez méthodiquement ces trois étapes pour diagnostiquer le problème en quelques secondes.

1. Commencez par la première ligne de la trace (souvent la plus longue). C'est là que Ruby a abandonné. Elle contient la localisation précise (fichier et ligne) et la nature de l'erreur. Dans 90% des cas, cette seule ligne suffit pour comprendre le problème.
2. Identifiez les fichiers qui vous appartiennent. La trace peut parfois inclure des lignes de code provenant de gems externes ou du code interne de Ruby. Concentrez-vous d'abord sur les lignes qui mentionnent vos propres fichiers (comme calculator.rb dans notre exemple). C'est là que se trouve très probablement la logique à corriger.
3. Remontez la pile pour obtenir le contexte. Si la cause de l'erreur n'est pas évidente à la première ligne, remontez d'un niveau dans la trace. La ligne suivante vous montrera qui a appelé le code défaillant et avec quels arguments potentiels. Cela vous aide à comprendre le 'pourquoi' : pourquoi cette méthode a-t-elle reçu une valeur incorrecte, par exemple ?

Conseil d'expert : que faire quand la trace ne suffit pas ?

Vous vous demandez peut-être ce qui se passe si la stack trace vous indique qu'une variable est nil, mais ne vous explique pas pourquoi elle est nil à ce moment précis. C'est une excellente question qui nous amène à la limite de l'analyse statique.

La stack trace est une photographie du moment de l'impact. Elle vous dit où et comment l'erreur s'est produite, mais elle ne vous montre pas l'état de votre programme juste avant. Si vous avez besoin de savoir quelle était la valeur de toutes vos variables à l'instant T, il vous faut un outil plus puissant.

C'est précisément le rôle du débogueur. Il vous permet de mettre le programme en pause juste avant la ligne de l'erreur pour inspecter l'environnement. Maintenant que vous savez lire la carte (la stack trace), vous êtes prêt à apprendre à utiliser la loupe (le débogueur), ce que nous allons voir dans la leçon suivante.