debug est le débogueur standard de Ruby, et Rails la place dans les groupes development et test du Gemfile de chaque nouvelle application. Si vous déboguez encore avec puts, elle est déjà installée.
Ce qu’elle fait et que les instructions d’affichage ne peuvent pas faire, c’est vous laisser garder votre position. Vous arrêtez une fois, puis vous explorez : lire le code source, ajouter d’autres points d’arrêt, les atteindre, remonter la pile d’appels, tout cela sans modifier un fichier ni redémarrer.
Ce que couvre cet article
- Trois façons d’entrer dans une session de débogage.
- Se déplacer dans le code avec
step,nextetcontinue. - Ajouter des points d’arrêt en cours de session, y compris dans d’autres fichiers.
- Parcourir la pile d’appels avec
backtrace,up,downetframe.
Prérequis
Pour un projet qui ne l’a pas :
Entrer dans une session
Trois points d’entrée, tous placés sur la ligne où vous voulez vous arrêter.
Le prompt vous indique où vous êtes :
irb pour IRB, rdbg pour le débogueur.
Le troisième mérite d’être connu, car binding.irb est une habitude difficile à abandonner. Si la gem debug est présente, exécuter n’importe quelle commande du débogueur depuis une session IRB vous fait basculer dans le débogueur et l’exécute. Vous n’avez jamais à revenir en arrière pour changer la ligne.
Retrouver ses repères
Deux commandes à exécuter lorsque vous avez perdu la trace de l’endroit où vous vous êtes arrêté :whereamiaffiche les dix lignes autour du point d’arrêt.list(oul) affiche le code source et accepte une plage :list 22-28.
help liste chaque commande, regroupée selon ce qu’elle fait. help backtrace explique l’une d’entre elles.
Entrer par binding.irb vous donne aussi accès au show_source propre à IRB, qui affiche le code source d’une constante ou d’une méthode sans quitter la session :
Se déplacer dans le code
Trois commandes, et la différence entre les deux premières est tout l’enjeu.
Sur une ligne qui appelle une méthode,
step vous emmène à l’intérieur de cette méthode. Continuez à avancer pas à pas, et vous finirez à l’intérieur de Rails lui-même, en train de lire le code source d’Active Record dans la même session. next exécute la ligne entière et s’arrête sur la ligne suivante.
Utilisez step quand vous suspectez l’appel. Utilisez next quand vous l’avez déjà écarté.
Ajouter des points d’arrêt sans quitter la session
C’est ce qui rend la session utile.break seul liste les points d’arrêt que vous avez déjà posés. Avec un argument, il en ajoute un.
continue vous y amène directement. L’alternative est de vous arrêter, modifier un fichier, redémarrer, puis avancer pas à pas pour revenir où vous étiez. Cela vous coûte l’état que vous aviez construit, et le fil de vos idées avec.
Parcourir la pile d’appels
backtrace (ou bt) liste les frames, chacune avec un index.
upremonte vers le frame appelant.downredescend vers l’endroit où vous vous êtes arrêté.frame 12(ouf 12) saute directement à un frame donné.
up se déplace vers des numéros d’index plus grands, ce qui se lit à l’envers par rapport à la liste affichée, jusqu’à ce que vous l’ayez fait une fois.
Dans n’importe quel frame, list affiche le code source de ce frame, et info affiche ses variables. info locals restreint cela aux variables locales. Se placer dans le frame d’un appelant pour lire les arguments qu’il a transmis est souvent plus rapide qu’avancer pas à pas pour voir ce qu’une méthode a reçu.
Déboguer ce que vous ne pouvez pas reproduire
Tout ce qui précède nécessite un point d’arrêt, qui nécessite que le problème survienne pendant que vous regardez. Les incidents en production ne coopèrent pas. C’est l’écart que AppSignal comble, et les deux approches se complètent plutôt que de s’opposer :- Le suivi des erreurs capture l’exception, sa backtrace et la requête qui l’a provoquée, que quelqu’un ait été en train de regarder ou non.
- Les traces de performance montrent l’appel tel qu’il s’est déroulé, avec les timings, ce qui est ce qui ressemble le plus à un
backtracepour une requête déjà terminée. - Time Detective montre ce que faisait le reste de l’application pendant que la trace s’exécutait. Un point d’arrêt ne peut pas vous donner cela après coup.
- Les paramètres de requête et les données personnalisées déposent les valeurs sur l’incident. C’est ce que
info localsvous donne localement, et c’est souvent la pièce manquante pour reproduire quelque chose. - Les exceptions que votre application rescue elle-même n’atteignent jamais Rails, donc rien ne les signale automatiquement. Signalez-les vous-même avec la gestion des exceptions.
Transcription
Transcrit à partir de la vidéo et légèrement édité : les sous-titres automatiques ont mal compris un certain nombre de noms de produits et d’API, et ceux-ci ont été corrigés.Lire la transcription
Lire la transcription
0:02 - Bonjour à tous, bienvenue dans un nouvel épisode ici sur GoRails. Dans l’épisode de cette semaine, nous allons voir comment mieux déboguer en utilisant la gem debug de Ruby. C’est donc une gem que vous devrez installer, ou que vous pouvez ajouter à votre Gemfile si vous travaillez avec un projet qui a un Gemfile. Et une chose intéressante, c’est que dans une nouvelle application Rails, si vous en créez une, comme je viens de le faire ici, j’ai créé une nouvelle application Rails appelée Blah. Si j’ouvre ça et qu’on va voir le Gemfile, on va voir, si on recherche debug ici, on va voir que la gem debug est ajoutée à votre Gemfile par défaut dans Rails, dans les groupes development et test, ce qui est génial.0:50 Ça nous donne donc la possibilité d’entrer dans une session de débogage en utilisant cette gem, et de parcourir notre code et de faire des choses plutôt astucieuses pour déboguer nos applications. Bon, j’ai donc ici notre application hackathon, et on va s’amuser un peu avec la gem debug ici et se familiariser avec certaines des commandes auxquelles on a accès, et comment les utiliser, et comment elles peuvent affecter la façon dont on suit notre code ici. Donc pour entrer dans une session de débogage, on a quelques options pour y arriver. La première chose qu’on peut faire, descendons dans cette méthode current, ou cette méthode latest ici, dans cette classe Event. Si je me place juste dans la première ligne, cette méthode ici, une chose qu’on peut faire, c’est taper
binding.irb, vous connaissez peut-être binding.irb.1:43 Et ça, quand on atteint ce point d’arrêt, on va entrer dans une session IRB, mais une fois dans cette session, on peut alors exécuter la commande debug ou n’importe quelle autre commande de la gem debug, et ça va nous faire tomber dans une session ou un prompt de console Ruby debug ici. Regardons donc ça d’abord. Je vais sauvegarder ça et passer à un autre onglet de terminal ici, et je vais juste entrer dans la console en mode sandbox. Pardonnez-moi d’utiliser un alias ici. Si vous voyez en haut, je sais que c’est probablement petit à lire, mais ici en haut, vous pouvez voir ce que RCS signifie ici.2:21 Ça exécute simplement bin rails console dash S. Vous entrez donc en mode sandbox, c’est mon petit alias shell. En tout cas, ici, je tape juste event et j’appelle ensuite cette méthode de classe latest ici. Si on appuie sur entrée ici, on voit qu’on a atteint ce point d’arrêt binding.irb, mais le prompt ici reflète qu’on est dans IRB, non ? Donc ce qu’on peut faire ici, pour entrer dans le prompt Ruby debug, c’est simplement taper debug, d’accord ?2:52 Si on fait ça, on voit que notre prompt change maintenant en RDBG. Et ça nous indique maintenant qu’on est ici dans la console Ruby debug. Bon, ceci étant fait, qu’est-ce qu’on peut faire ici maintenant ? Une chose qu’on peut faire, je vais juste effacer cette console tout en restant dans la console Ruby debug. Je vais juste effacer le terminal ici pour qu’on ait de la place pour travailler.3:16 Une chose qu’on peut faire, c’est utiliser la commande show_cmds ici, appuyer sur entrée, et on peut voir une liste de toutes les commandes disponibles à laquelle on a accès dans cette session ici. En regardant certaines de ces commandes ici, on a quelques commandes IRB, on a des commandes de débogage, quelques commandes diverses, quelques commandes de contexte, et ainsi de suite. Commençons donc à regarder certaines de celles que je trouve les plus pratiques à connaître. La première chose, c’est aussi une commande disponible dans IRB, mais c’est la commande whereami. Si vous oubliez jamais où vous avez posé le point d’arrêt et à quoi ressemble le code autour, vous pouvez taper cette commande, et ça va afficher ça et vous montrer les 10 lignes autour de l’endroit où se trouve ce point d’arrêt.3:58 On voit ici, disant 13 à 22 dans ce fichier ici. Ça montre donc 10 lignes, plus ou moins cinq, autour de l’endroit où se trouve ce point d’arrêt. C’est donc comme ça qu’on peut toujours retrouver ce contexte sans avoir à défiler, ou si on a effacé le terminal, on peut retrouver ce contexte de l’endroit où on se trouve dans cette session ici. Donc whereami, une excellente commande à connaître. Aussi, une autre qui est sympa ici, c’est la commande list.4:28 Bon, beaucoup des commandes disponibles dans la gem Ruby debug ont des raccourcis. Pour list, vous pouvez simplement taper L, ou vous pouvez taper le mot complet list. Et une chose que vous pouvez faire, c’est lui donner une plage de numéros de ligne. Par exemple, en ce moment on ne peut voir que de 13 à 22, si je voulais voir à quoi ressemble 22 à disons 28, une chose que je peux faire, c’est taper list ou taper L, je vais juste taper list pour l’instant, et dire 22 tiret 28. D’accord.5:05 Maintenant on appuie sur entrée ici. Maintenant on voit les lignes qu’on a demandées de ce fichier, exactement de 22 à 28. La commande list est donc géniale. Une des autres commandes que j’aime vraiment, c’est la commande show_source. On peut donc dire show_source et ensuite lui donner, vous savez, une chaîne comme une constante qu’on veut regarder.5:22 Ça peut être une constante, on peut lui passer une méthode qu’on veut voir, mais je vais juste faire cette constante event pour l’instant. Donc show_source event, on appuie sur entrée ici. On peut voir, oups, on peut voir tout le code source de cette classe event ici. Juste en appelant ça. On n’a donc jamais à quitter cette session de console ici et retourner dans notre éditeur pour retrouver cette information.5:48 De plus, on peut aussi regarder juste, vous savez, le code source de notre méthode. Regardons ça maintenant. Regardons si on voulait regarder, vous savez, à quoi ressemble le code source de la méthode to-param ici. Et on n’avait pas déjà ça ouvert. Regardons comment faire ça.6:03 Donc si on voulait regarder la méthode to-param, on pourrait dire show_source et ensuite lui donner la chaîne event. Et ensuite on peut utiliser le dièse parce que c’est dans notre symbole hash, excusez-moi. On peut utiliser ce symbole, ou ça, pour indiquer qu’on veut regarder la méthode d’instance to-param, non ? Donc on va dire hash to-param, fermer notre chaîne, appuyer sur entrée. Et maintenant on voit le code source de la méthode to-param.6:27 Si on voulait regarder la méthode de classe current, alors on pourrait dire show_source et ensuite dire event. Et ensuite on pourrait faire les deux points et ensuite current, juste ici, fermer notre chaîne. Maintenant on voit le code source de la méthode de classe current, non ? Et on est toujours dans cette session Ruby debug. On n’a jamais eu à quitter cette console et retourner à notre code source.6:54 On peut tout faire d’ici. C’est donc cool. Une de mes, une des autres commandes que j’aime vraiment, c’est juste la commande info. Si on tape info ici, on peut voir, vous savez, une grande liste d’infos. Ce sont, vous savez, toutes les variables et variables d’instance et autres choses qu’on a disponibles maintenant dans le contexte où on se trouve.7:11 On peut donc alors, vous savez, prendre ça, par exemple. On peut prendre at generated associated methods, non ? On peut copier ça. Et ça, ça pointe vers un objet ici, où sont les méthodes disponibles dans cet objet. On peut donc dire at generated associated methods dot methods dot sort, par exemple, et avant d’exécuter ça, je vais juste effacer la console, appuyer sur entrée.7:34 Et maintenant on voit toutes les méthodes disponibles dans cet objet là, non ? C’est vraiment cool. Et encore une fois, si vous oubliez où vous êtes, en train d’expérimenter, quoi que ce soit. Rappelez-vous, whereami ? Et vous pouvez voir où vous êtes actuellement.7:46 Maintenant qu’on a retrouvé notre contexte, regardons une autre commande disponible pour nous. La commande step. En regardant la documentation ici, la commande step, vous pouvez juste dire step seul, ou lui donner un nombre. Et ça, la commande step vous permet d’entrer dans le code. Je pense à ça comme entrer dans les points d’exécution tout au long du programme.8:13 Vous pouvez donc faire step, vous savez, juste un pas, plusieurs pas, et ça vous mène au prochain, comme ils disent ici, prochain point interruptible. Si on fait un step là où on est en ce moment, en ce moment on est sur la zone 18 ici. Si on dit step sans nombre, on voit qu’on steppe jusqu’à la ligne suivante ici, mais on commence au début de la ligne ici. Donc en ce moment, cette méthode actuelle n’a pas été appelée, et aussi, vous savez, l’autre moitié de cette condition n’a pas encore été exécutée non plus. On est donc en quelque sorte au début de cette ligne ici avant que quoi que ce soit d’autre ne se passe.8:50 Maintenant, si on fait step encore une fois, on va voir qu’on se retrouve dans la méthode current maintenant, d’accord ? Donc on a fait un step, on était juste ici. Sur la ligne 19, au début ici, on entre dans cet appel ici vers current. Ça steppe donc en quelque sorte vers ce prochain point d’exécution, c’est comme ça que j’aime y penser. Donc maintenant on est ici, non ?9:12 Et donc vous pouvez faire des choses ici et vous amuser avec ce code ici, si vous voulez, vous savez, vous pouvez juste voir, oh, qu’est-ce que first up publish me donne, vous savez, avant d’appeler ce order et ainsi de suite, non ? Maintenant, ce qui est amusant ici, c’est que si vous continuez à stepper à un certain point, du moins dans ce cas ici en appelant ces méthodes de classe ici, on steppe encore, on voit qu’on est maintenant descendu dans le code source d’Active Record scoping named.rb, non ? On est donc maintenant à l’intérieur de code source Rails ici, dans lequel on a steppé en utilisant debug et la commande step pour naviguer à travers l’exécution ou les points interruptibles, comme ils disent, dans le code ici. Vous pouvez donc continuer ce voyage ici et stepper et stepper, et ça va juste continuer, vous savez, vers les prochains points interruptibles, le prochain point, et ainsi de suite, si vous voulez, vous savez, poursuivre votre programme, arrêter de stepper comme ça et continuer jusqu’au prochain point d’arrêt que vous avez posé, s’il, vous savez, tombe dans le chemin d’exécution ici, ou juste continuer votre programme, et s’il n’y a pas d’autres points d’arrêt, aller jusqu’à la fin, vous pouvez taper continue ou con en plus court, mais je vais juste faire la forme longue ici, continue, on va appuyer sur continue, et ensuite on voit que notre programme se déroule complètement, il récupère ce latest event, et on est maintenant de retour dans la session IRB, donc on est sorti de la session de débogage et maintenant on est de retour dans la session IRB. Je vais donc sortir de la session IRB ici et retourner dans la console, et regardons quelques autres choses.10:49 On est donc de nouveau ici, de retour à notre point d’arrêt, il y a aussi la commande next. Si on regarde la documentation là pour next, en comparaison avec step où ça entre dedans, next passe par-dessus et ça reprend le programme jusqu’à la ligne suivante. Regardons donc ce qui se passe en utilisant next ici. Donc on est sur la ligne 18 juste ici, si on steppe vers next, on voit qu’on est sur la ligne suivante. D’accord, c’était similaire à ce qu’on a fait avec step, non ?11:18 On va donc au point suivant juste ici, non, le prochain point interruptible, et on est au début ici, current n’a pas été appelé, ni previous non plus, mais alors que la dernière fois, quand on a fait step, on s’est retrouvé dans la méthode current, voyons ce qui se passe quand on fait next ici. Donc on voit ici que ça a sauté par-dessus, non ? Toute cette ligne ici, ça a exécuté cette ligne de code et ensuite a sauté à la ligne suivante. On n’a donc pas eu tous les détails, si vous voulez, de la méthode current et ensuite dans Active Record, non ? On a sauté par-dessus toute cette ligne, elle a fait son travail, et maintenant on est sur la ligne suivante, qui se trouve être pour nous la fin de cette définition de méthode ici.12:05 Bon, je vais donc sortir de cette session, et ensuite je vais retourner dans notre console Rails ici, et je vais atteindre notre point d’arrêt à nouveau en appelant event dot latest, d’accord. Et maintenant on a utilisé binding.irb et ensuite on est entré dans la session Ruby debug en appelant des commandes de la gem Ruby debug. C’est donc une façon d’y arriver. Si vous utilisez binding.irb et ensuite appelez une des commandes de debug, ça va automatiquement exécuter cette commande et vous mettre dans, ou vous mettre dans, ça va automatiquement vous mettre dans cette session de débogage et exécuter cette commande que vous avez utilisée. Si vous ne voulez pas exécuter une commande et voulez juste entrer dans la session de débogage, vous pouvez simplement taper debug, d’accord.12:52 Et ça va vous mener dans la session de débogage. Et si vous tapez whereami, vous verrez que vous êtes toujours au même endroit dans le code, non ? On est juste ici. De plus, on voit une liste de quelques frames ici, et on va arriver aux frames dans un instant. Mais c’est comme ça que vous pouvez entrer dans le débogueur, à travers la gem Ruby debug via IRB ou binding.irb.13:19 Alternativement, si on sort d’ici, on a quelques autres options. On peut donc aussi faire binding.b, d’accord. Et si on entre à nouveau dans notre console, notre console Rails, et qu’on atteint ce point d’arrêt créé par binding.b, on va voir qu’on tombe immédiatement dans une session de débogage. On saute la partie IRB et on va directement dans le débogueur. C’est donc une méthode qui vient de la gem debug.13:46 C’est une forme courte de binding.break. Vous pouvez donc taper binding.break, le mot complet break ici, ou vous pouvez juste faire binding.b en plus court. C’est donc une façon d’aller directement dans la session de débogueur sans avoir à faire binding.irb. Mais si, vous savez, binding.irb est l’habitude difficile à abandonner. Si vous avez la gem debug dans votre application, vous pouvez toujours y entrer via binding.irb.14:11 Regardons rapidement une autre façon d’y entrer. On peut donc faire bind dot IRB, binding.b, et ainsi de suite, l’autre chose qu’on peut faire, c’est appeler debugger, juste comme ça, d’accord. Maintenant, si on retourne dans notre console Rails, et qu’on fait ensuite event dot latest, on voit qu’on atteint alors le debugger ici, et on tombe encore une fois directement dans une session de débogage. Ce sont donc vos façons d’entrer dans la gem debug, non ? Maintenant, regardons la commande break, parce que celle-ci est vraiment cool.14:46 Donc avec la commande break seule, c’est aussi B en plus court, mais je vais utiliser la forme longue ici. break seul, si vous appuyez sur entrée là-dessus, ça va juste vous retourner une liste de tous les points d’arrêt que vous avez posés, si vous en avez posé. On n’en a pas actuellement. Cependant, une chose cool ici, c’est que vous pouvez poser des points d’arrêt supplémentaires depuis cette session ici, non ? Disons donc qu’on voulait ajouter un point d’arrêt après la ligne 22 ici, d’accord ?15:15 Donc sur la ligne 23, on veut ajouter un point d’arrêt. Ce qu’on peut donc faire, c’est dire break ou B, et ensuite simplement 23, d’accord ? Et maintenant vous voyez qu’on obtient cette sortie ici, ligne de point d’arrêt, et dans quel fichier c’était, et ensuite quelle ligne, d’accord ? Maintenant, si on tape la commande break ici, on va voir la même sortie. On a donc maintenant un point d’arrêt posé.15:37 Et maintenant, si on voulait sauter directement d’où on est, tant que le prochain point d’arrêt qu’on a posé est dans le chemin d’exécution de notre programme, ce qu’on peut faire, c’est taper continue, d’accord ? Et ça va exécuter à partir de là où on est dans notre programme actuellement, sur la ligne 18 ici, où ce debugger a été posé, et ça va parcourir notre programme jusqu’à ce qu’on atteigne un autre point d’arrêt, ce qui va être notre cas, parce que sur la toute prochaine ligne ici on appelle current, et on a posé un point d’arrêt à l’intérieur de cette méthode sur la ligne 23. On appuie sur continue ici. On voit que le code s’exécute complètement, et il s’arrête juste là au début de la ligne 23 ici dans current. C’est donc vraiment cool.16:16 Vous savez, vous pouvez poser des points d’arrêt supplémentaires et les atteindre, vous savez, tant qu’ils sont dans le chemin d’exécution, vous pouvez continuer jusqu’à eux, et continuer à les atteindre et les ajouter au besoin, sans avoir à quitter cette session, retourner à votre code source, poser un nouveau point d’arrêt là où vous voulez, tout réexécuter, encore une fois, les atteindre tous, et ainsi de suite. Vous pouvez juste rester, vous savez, dans le même contexte ici, ne pas briser votre concentration, et travailler à déboguer quelque chose. Vous n’êtes aussi pas limité à poser des points d’arrêt supplémentaires dans le fichier actuel dans lequel vous êtes. Regardons donc ça ensuite. Bon, disons qu’on débogue quelque chose autour de cet appel de méthode ici, cette méthode full, non ?16:56 Quelque chose se passe, on ne sait pas vraiment quoi, on veut juste atteindre un debugger ici et commencer à déboguer ce truc, non ? On va donc poser un debugger là, et ensuite on va entrer dans notre console Rails ici, et ensuite on va juste dire team égal team.first pour commencer ici, et ensuite on va juste dire team.full, point d’interrogation, non ? Et on atteint notre point d’arrêt debugger, on est dans une session de débogueur en ce moment, non ? Et maintenant on veut ajouter, on voit qu’ils nous appellent cette méthode at or above capacity sur team users. Donc ce qu’on peut faire maintenant, si on sait, on sait que c’est dans le fichier team user, on ne sait pas sur quelle ligne c’est, si on savait sur quelle ligne c’était, une chose qu’on pourrait faire, c’est dire, et je sais juste ici que c’est sur la ligne 16, j’ai déjà regardé, retour ici, une chose qu’on peut faire, c’est ajouter un point d’arrêt à ce fichier et à cette ligne, on pourrait donc dire break, et ensuite on doit passer le chemin vers le fichier, ça va être long, alors patientez, je vais peut-être accélérer ici, app, models, team, user, et ensuite deux points 16, d’accord ?18:02 On a donc ajouté un point d’arrêt à ce fichier et à cette ligne, et maintenant si on devait taper continue ou cont en plus court, C-O-N-T, on appuie sur entrée ici, on voit que notre programme a exécuté jusqu’à ce qu’on atteigne ce point d’arrêt ici, qu’on a posé, non ? Maintenant, on aurait probablement pu utiliser step pour parcourir tout ça et arriver ici aussi, mais je voulais juste montrer un exemple de comment on peut poser des points d’arrêt dans d’autres fichiers. Maintenant, une chose cool que vous pouvez faire ici, c’est qu’au lieu de ce chemin ici et de passer un numéro de ligne, vous pouvez simplement passer la classe et la méthode et poser un point d’arrêt de cette façon, alors regardons rapidement comment faire ça. Bon, retour, on entre dans une autre session de console Rails ici, disons team égal team.first à nouveau, d’accord ? Et ensuite on va dire team.full, on va atteindre ça, un point d’arrêt debugger, et maintenant on veut poser un point d’arrêt depuis là où on est actuellement sur cette méthode là-bas dans le fichier de classe team user.19:05 On pourrait faire ça comme on a vu en passant le chemin vers ce fichier et le numéro de ligne, mais disons qu’on ne connaît pas le numéro de ligne, et on ne veut pas retourner dans notre éditeur, ouvrir ce fichier, et ajouter le point d’arrêt là, parce que si on va juste faire ça, on pourrait tout aussi bien ajouter le debugger pendant qu’on est juste là et redémarrer tout ce processus, mais on essaie de garder notre contexte ici et de ne pas perdre notre concentration sur ce qu’on fait actuellement. On veut rester dans le rythme et sur la bonne voie et continuer sur le chemin d’essayer de déboguer quelque chose ici. Donc ce qu’on peut faire ici, si on ne connaît pas le numéro de ligne, on peut faire correspondre la classe et le nom de la méthode. Comme c’est une méthode de classe ici sur team user, on peut simplement dire break on team user dot at or above capacity, point d’interrogation, d’accord, et ensuite on peut appuyer sur entrée là-dessus, et ensuite on voit que ce point d’arrêt sur une méthode a été appelé, et on voit qu’il a été ajouté au fichier team user sur la ligne 16, non, et comme on l’a vu précédemment, c’était exactement la ligne sur laquelle cette méthode est définie. Donc maintenant, si on appuie sur continue ici ou cont C-O-N-T en plus court ici, si on appuie sur entrée, notre programme va continuer jusqu’à ce qu’il atteigne ce prochain point d’arrêt.20:26 On fait donc ça, et on voit, on y est. On est au début ici de cette méthode ici. On est à l’intérieur du corps de la méthode, au début de cette ligne. Bon, terminons cette vidéo en regardant les frames, d’accord. Je suis donc de retour dans la console Rails ici.20:39 J’ai récupéré la première team. Je vais juste appeler team.full pour qu’on atteigne notre point d’arrêt à nouveau. D’accord, maintenant on est dans une session de débogueur. Donc ce qu’on peut faire, comme vous pouvez le voir juste ici, ça nous donne un affichage des, disons, deux premiers frames ici, et ensuite ça dit dans 27 frames, et ensuite ça dit utilisez BT pour tous les frames. La commande BT va donc lister tous les frames auxquels on a accès en ce moment.21:06 Je vais donc juste faire un peu de place ici dans notre terminal, et ensuite exécutons cette commande BT et voyons ce qu’on obtient là. Aussi, BT est juste l’abréviation de back trace. Comme vous pouvez le voir ici, on obtient une auto-complétion. Vous pouvez donc taper le mot complet back trace ou BT pour obtenir cette liste ici. Et ce qu’on voit ici quand on exécute cette commande, c’est qu’on obtient une liste de tous les frames qu’on a en ce moment.21:31 C’est essentiellement une stack trace ici, non ? Donc c’est le frame dans lequel on est, où on a atteint notre point d’arrêt. Et ensuite c’est tout ce qui s’est passé avant qu’on atteigne ce point d’arrêt, d’accord ? Donc ce qu’on peut faire ici, c’est utiliser ces identifiants ou numéros d’ID au début ici, le, vous savez, dièse zéro, dièse un, ou hash un, hash deux. On peut les utiliser pour sauter directement à un frame, ou on peut avancer un par un.22:03 Donc la façon de, si on veut juste aller, ça va être un peu étrange. Si on regarde cette liste, on penserait qu’on veut aller ici en bas, mais en réalité, ce qu’on veut faire, c’est utiliser la commande up pour monter d’un frame, et pensez juste que quel que soit le frame actuel où vous êtes, up va l’incrémenter vers, vous savez, le numéro suivant plus grand, d’accord ? Donc si on est ici et qu’on veut aller à main, on peut simplement taper la commande up. Et maintenant on voit que notre frame actuel est main juste ici. Si on tape L ou list juste ici, on voit du code source pour le frame actuel, d’accord ?22:39 Maintenant, si on veut retourner au frame duquel on vient juste de venir, on peut taper down. Donc si on descend, on peut voir qu’on est maintenant de retour ici à ce frame, et encore une fois, on peut taper list pour voir le code source, et on voit le code source juste ici pour ce frame actuel. Maintenant, en plus, on peut sauter à un frame particulier. Par exemple, si on veut aller à ce frame ici, frame 12, on peut taper soit F et ensuite le numéro d’identifiant, qui est 12 dans notre cas, soit la commande complète, qui est frame, et ensuite 12, d’accord ? Et maintenant on voit qu’on est dans le frame 12, qui est ce fichier IRB ici.23:23 Et si on tape L ou list, on peut voir le code source pour ce frame ici. C’est donc une fonctionnalité vraiment cool. Ça vous permet de monter et descendre la stack trace et de regarder des choses dans différents contextes de frame. Et encore une fois, une fois que vous êtes dans un frame, vous pouvez taper list comme je l’ai fait pour voir le code source. Vous pouvez aussi taper info pour voir les, vous savez, variables locales, variables d’instance et autres choses disponibles que vous avez dans ce contexte.23:52 C’est donc vraiment cool aussi. Vous savez, info est génial. Il y a aussi quelques arguments que vous pouvez passer à la commande info. Vous pouvez trouver plus d’informations à ce sujet dans le readme de la gem debug. Mais par exemple, vous pouvez dire info locals, et ça va juste vous redonner les variables locales seulement, et pas tout le reste.24:14 Une dernière chose, si vous êtes dans la session de débogage et que vous ne vous souvenez pas des commandes ou de ce que vous pouvez faire ici, il y a une option help. Vous pouvez simplement taper help, et ça va vous donner une liste de toutes les commandes disponibles que vous avez à l’intérieur de la session de débogage ici, avec de jolis petits en-têtes séparant les différentes sections de commandes, commandes de points d’arrêt, commandes de flux de contrôle, et ainsi de suite. Et en plus, comme vous le voyez ici, vous pouvez juste taper help, obtenir la liste complète, ou help, et ensuite une commande, pour obtenir de l’aide juste pour cette commande. Par exemple, disons help back trace, non ? Et ensuite on voit les informations pour toutes les commandes back trace.24:53 Donc avec ça, je vais terminer cette vidéo ici. J’espère que ça vous a exposé à quelques nouvelles choses que vous avez, de nouveaux outils que vous pouvez utiliser et avoir à votre disposition pour mieux vous aider à déboguer les erreurs d’application. Aussi, c’était plutôt une approche introductive à cette gem, il y a beaucoup plus à lire dans le readme, beaucoup de choses puissantes ici. Mon espoir, ne me citez pas là-dessus, mais je vais essayer. Mon objectif est de faire une vidéo de suivi ici, en espérant avec quelqu’un des mainteneurs de cette gem, et voir si on peut collaborer sur une vidéo et peut-être creuser certaines des utilisations plus avancées de cette gem et fournir ce niveau supérieur de débogage.25:47 On verra donc ce qui se passe là. Je vais essayer de mon mieux d’avoir quelqu’un de l’équipe ici pour me rejoindre dans un appel vidéo et creuser ces choses, mais quoi qu’il en soit, utilisez définitivement cette gem. Elle est géniale, elle est vraiment puissante. Et oui, donc là-dessus, je vous laisse ici, et bon débogage.Tutoriels associés
À propos de ce tutoriel
Ce tutoriel résume un screencast GoRails sur le débogage avec la gemdebug de Ruby, présenté par Collin. Le screencast est l’œuvre originale. GoRails la publie, ainsi que le reste de la série, sur gorails.com.