Skip to main content
Präsentiert von Collin für GoRails. Erneut veröffentlicht auf AppSignal am 19. September 2026. Das debug-Gem ist Rubys Standarddebugger. Rails legt es in jeder neuen Anwendung standardmäßig in die development- und test-Gruppen des Gemfile. Wenn Sie noch mit puts debuggen, ist es bereits installiert. Was es kann und Print-Anweisungen nicht können: Sie behalten Ihre Position bei. Sie halten einmal an und erkunden dann: Quellcode lesen, weitere Breakpoints hinzufügen, zu ihnen laufen und den Stack wieder nach oben gehen. All das, ohne eine Datei zu bearbeiten oder neu zu starten.

​
Was dieser Artikel behandelt

  • Drei Wege in eine Debug-Sitzung.
  • Sich mit step, next und continue durch den Code bewegen.
  • Breakpoints während der Sitzung hinzufügen, auch in anderen Dateien.
  • Den Stack mit backtrace, up, down und frame durchlaufen.

​
Voraussetzungen

Für ein Projekt, das es noch nicht hat:

​
In eine Sitzung gelangen

Drei Einstiegspunkte, alle platziert auf der Zeile, an der Sie anhalten möchten. Der Prompt zeigt Ihnen, wo Sie sich befinden: irb für IRB, rdbg für den Debugger. Die dritte Möglichkeit ist entscheidend, denn binding.irb ist eine schwer abzulegende Gewohnheit. Wenn das debug-Gem vorhanden ist, können Sie jeden beliebigen Debugger-Befehl aus einer IRB-Sitzung heraus ausführen. Das versetzt Sie in den Debugger und führt den Befehl aus. Sie müssen nie zurückgehen und die Zeile ändern.

​
Ihre Position finden

Zwei Befehle, die Sie ausführen, wenn Sie den Überblick verloren haben, wo Sie angehalten haben:
  • whereami gibt die 10 Zeilen um den Breakpoint aus.
  • list (oder l) gibt Quellcode aus und akzeptiert einen Bereich: list 22-28.
help listet jeden Befehl auf, gruppiert nach dem, was er tut. help backtrace erklärt einen davon. Der Einstieg über binding.irb gibt Ihnen außerdem Zugriff auf IRBs eigenes show_source, das den Quellcode einer Konstante oder Methode ausgibt, ohne dass Sie die Sitzung verlassen:

​
Sich durch den Code bewegen

Drei Befehle, und der Unterschied zwischen den ersten beiden ist der eigentliche Punkt. Auf einer Zeile, die eine Methode aufruft, bringt Sie step in diese Methode hinein. Steppen Sie weiter, landen Sie irgendwann in Rails selbst und lesen den Quellcode von Active Record in derselben Sitzung. next führt die gesamte Zeile aus und hält auf der folgenden an. Verwenden Sie step, wenn Sie den Aufruf verdächtigen. Verwenden Sie next, wenn Sie ihn bereits ausgeschlossen haben.

​
Breakpoints hinzufügen, ohne die Sitzung zu verlassen

break allein listet die bereits gesetzten Breakpoints auf. Mit einem Argument fügt es einen hinzu.
Die erste Form ist eine Zeile in der aktuellen Datei. Die zweite ist ein Pfad und eine Zeile in einer beliebigen Datei. Die dritte ist eine Klasse und Methode, ganz ohne Zeilennummer. Greifen Sie zur letzten Form. Es ist die einzige ohne Zeilennummer, sodass Sie nie eine in Ihrem Editor nachschlagen müssen. Dann läuft continue bis dorthin. Die Alternative ist: anhalten, eine Datei bearbeiten, neu starten und wieder zu der Stelle zurücksteppen, an der Sie waren. Es kostet Sie den aufgebauten Zustand und mit ihm den Gedankengang.

​
Den Stack durchlaufen

backtrace (oder bt) listet die Frames auf, jeden mit einem Index.
  • up wechselt zum aufrufenden Frame.
  • down wechselt zurück in Richtung der Stelle, an der Sie angehalten haben.
  • frame 12 (oder f 12) springt direkt zu einem bestimmten Frame.
up bewegt sich zu größeren Indexnummern hin, was sich gegen die gedruckte Liste rückwärts liest, bis Sie es einmal ausprobiert haben. In jedem Frame zeigt list den Quellcode dieses Frames, und info zeigt seine Variablen. info locals schränkt das auf lokale Variablen ein. In einem aufrufenden Frame zu stehen, ist oft schneller, als vorwärts zu steppen, um zu sehen, was eine Methode empfangen hat. Von dort aus lesen Sie die übergebenen Argumente.

​
Debugging von etwas, das Sie nicht reproduzieren können

Alles oben Genannte braucht einen Breakpoint, und der braucht das Problem, während Sie zuschauen. Fehler in der Produktion kooperieren nicht. AppSignal schließt diese Lücke, und die beiden Arbeitsweisen ergänzen sich:
  • Fehler-Tracking erfasst die Exception, ihren Backtrace und den Request, der sie ausgelöst hat, egal ob jemand zugeschaut hat oder nicht.
  • Performance-Traces zeigen den Aufruf, wie er geschehen ist, mit Timings. Ein Trace kommt einem backtrace für einen bereits abgeschlossenen Request am nächsten.
  • Time Detective zeigt, was der Rest der Anwendung getan hat, während der Trace lief. Ein Breakpoint kann Ihnen das nachträglich nicht geben.
  • Request-Parameter und benutzerdefinierte Daten legen die Werte auf dem Issue ab. Das ist es, was info locals Ihnen lokal gibt, und es ist meist das fehlende Puzzleteil, wenn Sie etwas reproduzieren.
  • Eine Exception, die mit einem einfachen rescue abgefangen wird, erreicht Rails nie, sodass nichts sie automatisch meldet. Melden Sie diese selbst mit Exception-Handhabung, oder fangen Sie sie mit Rails.error.handle ab, was AppSignal standardmäßig meldet.
Das nützliche Muster ist: Lassen Sie sich von AppSignal sagen, was fehlgeschlagen ist und mit welchen Eingaben. Verwenden Sie diese Eingaben dann, um es lokal zu reproduzieren und einen Breakpoint zu setzen.

​
Transkript

Aus dem Video transkribiert und leicht bearbeitet. Die automatische Untertitelung hat mehrere Produkt- und API-Namen falsch verstanden, und diese wurden korrigiert.
0:02 - Hallo zusammen, willkommen zurück zu einer weiteren Episode hier bei GoRails. In der Episode dieser Woche schauen wir uns besseres Debugging mit dem Ruby-debug-Gem an. Das ist also ein Gem, das Sie installieren müssen, oder Sie können es zu Ihrem Gemfile hinzufügen, wenn Sie mit einem Projekt mit einem Gemfile arbeiten. Und eine schöne Sache ist, dass bei einer neuen Rails-App, wenn Sie sie aufsetzen, wie ich es hier gerade gemacht habe – ich habe eine neue Rails-App namens Blah aufgesetzt. Wenn ich das öffne und wir uns das Gemfile ansehen, sehen wir, wenn wir nach debug suchen, dass das debug-Gem standardmäßig in Rails zu den development- und test-Gruppen Ihres Gemfiles hinzugefügt wird, was großartig ist.0:50 Das gibt uns also die Möglichkeit, in eine Debug-Sitzung mit diesem Gem zu springen und durch unseren Code zu gehen und ein paar ziemlich raffinierte Dinge zu tun, um unsere Anwendungen zu debuggen. Okay, ich habe hier also unsere Hackathon-Anwendung, und wir werden hier ein bisschen mit dem debug-Gem herumspielen und ein Gefühl für einige der Befehle bekommen, auf die wir Zugriff haben, und wie man sie benutzt und wie sie beeinflussen können, wie wir hier durch unseren Code verfolgen. Um also in eine Debug-Sitzung zu gelangen, haben wir ein paar Optionen. Das erste, was wir tun können: Gehen wir hinunter zu dieser current- oder dieser latest-Methode hier in dieser Event-Klasse. Wenn ich einfach in die erste Zeile dieser Methode hier hüpfe, können wir zum Beispiel binding.irb eingeben, vielleicht sind Sie mit binding.irb vertraut.1:43 Und wenn wir diesen Breakpoint erreichen, gelangen wir in eine IRB-Sitzung, aber sobald wir in dieser Sitzung sind, können wir dann den debug-Befehl oder einen der anderen Befehle aus dem debug-Gem ausführen, und das wird uns dann in eine Ruby-debug-Konsolensitzung oder einen Prompt hier fallen lassen. Schauen wir uns das also zuerst an. Ich speichere das und wechsle zu einem anderen Terminal-Tab hier, und ich springe einfach in die Konsole im Sandbox-Modus. Verzeihen Sie, dass ich hier einen Alias benutze. Wenn Sie oben – ich weiß, es ist wahrscheinlich klein zu lesen, aber hier oben können Sie sehen, was RCS hier bedeutet.2:21 Es führt einfach bin rails console dash S aus. Sie landen also im Sandbox-Modus, das ist mein kleiner Shell-Alias. Wie dem auch sei, hier tippe ich einfach event ein und rufe dann diese Klassenmethode latest auf. Wenn wir hier Enter drücken, sehen wir, dass wir diesen binding.irb-Breakpoint erreicht haben, aber der Prompt hier zeigt, dass wir in IRB sind, richtig? Was wir hier also tun können, um in den Ruby-debug-Prompt zu gelangen, ist einfach debug einzutippen, okay?2:52 Wenn wir das tun, sehen wir, dass sich unser Prompt jetzt zu RDBG ändert. Und das zeigt uns jetzt, dass wir uns hier in der Ruby-debug-Konsole befinden. Nachdem das erledigt ist, was können wir jetzt hier tun? Eine Sache, die wir tun können – ich lösche gerade diese Konsole, während wir weiterhin in der Ruby-debug-Konsole bleiben. Ich lösche einfach das Terminal hier, damit wir etwas Platz zum Arbeiten haben.3:16 Eine Sache, die wir tun können, ist den Befehl show_cmds zu benutzen, Enter drücken, und dann können wir eine Liste aller verfügbaren Befehle sehen, auf die wir in dieser Sitzung Zugriff haben. Wenn wir uns also einige dieser Befehle hier ansehen, haben wir einige IRB-Befehle, einige Debugging-Befehle, ein paar sonstige Befehle, einige Kontext-Befehle und so weiter. Schauen wir uns also einige der Befehle an, die ich am nützlichsten finde. Als erstes – das ist auch ein Befehl, der in IRB verfügbar ist, aber es ist der whereami-Befehl. Wenn Sie jemals vergessen, wo Sie den Breakpoint gesetzt haben und wie der Code darum herum aussieht, können Sie diesen Befehl eingeben, und er zeigt Ihnen das an und zeigt Ihnen die 10 Zeilen um die Stelle, an der dieser Breakpoint liegt.3:58 Wir sehen hier genau, dass 13 bis 22 in dieser Datei hier steht. Es zeigt also 10 Zeilen plus oder minus fünf um die Stelle, an der dieser Breakpoint liegt. So können wir also immer diesen Kontext zurückholen, ohne herumscrollen zu müssen, oder wenn wir das Terminal gelöscht haben, können wir diesen Kontext darüber zurückbekommen, wo wir uns in dieser Sitzung befinden. whereami ist also ein großartiger Befehl. Auch schön hier ist der list-Befehl.4:28 Nun, viele der Befehle, die im Ruby-debug-Gem verfügbar sind, haben Abkürzungen. Für list können Sie also einfach L eingeben, oder Sie können das volle Wort list schreiben. Und eine Sache, die Sie tun können, ist, ihm einen Bereich von Zeilennummern zu geben. Zum Beispiel können wir gerade nur 13 bis 22 sehen. Wenn ich sehen wollte, wie 22 bis sagen wir 28 aussieht, kann ich list oder L eingeben – ich tippe jetzt einfach list und dann 22 bis 28. Okay.5:05 Wenn wir jetzt hier Enter drücken, sehen wir die Zeilen, die wir aus dieser Datei angefordert haben, genau bei 22 bis 28. Der list-Befehl ist also großartig. Einer der anderen Befehle, die ich wirklich mag, ist der show_source-Befehl. Wir können also show_source sagen und ihm dann sozusagen einen String einer Konstante geben, die wir nachschlagen wollen.5:22 Es kann eine Konstante sein, wir können eine Methode angeben, die wir sehen wollen, aber ich mache das jetzt einfach mit dieser Event-Konstante. Also show_source Event, Enter drücken. Wir können, oh, wir können den gesamten Quellcode für diese Event-Klasse hier sehen. Einfach durch den Aufruf. Wir müssen diese Sitzung also nie verlassen und zurück zu unserem eigentlichen Editor gehen, um diese Informationen nachzuschlagen.5:48 Zusätzlich können wir uns auch den Quellcode für unsere Methode ansehen. Schauen wir uns das jetzt an. Schauen wir uns an, wie der Quellcode für die to-param-Methode hier aussieht. Und das hatten wir noch nicht offen. Schauen wir, wie man das macht.6:03 Wenn wir also nach der to-param-Methode schauen wollten, könnten wir show_source sagen und ihm dann den String event geben. Und dann können wir das Rautezeichen verwenden, weil es in unserem Hash-Symbol ist, Entschuldigung. Wir können dieses Symbol verwenden, um zu zeigen, dass wir die Instanzmethode to-param nachschlagen wollen, richtig? Wir sagen also Raute to-param, schließen unseren String, Enter drücken. Und jetzt sehen wir den Quellcode für die to-param-Methode.6:27 Wenn wir nach der current-Klassenmethode schauen wollten, könnten wir show_source sagen und dann event sagen. Und dann könnten wir den Doppelpunkt und dann current machen, genau hier, unseren String schließen. Jetzt sehen wir den Quellcode für die current-Klassenmethode, richtig? Und wir sind immer noch in dieser Ruby-debug-Sitzung. Wir mussten diese Konsole nie verlassen und zurück zu unserem Quellcode gehen.6:54 Wir können das alles von hier aus tun. Das ist also cool. Einer meiner – einer der anderen Befehle, die ich wirklich mag, ist einfach der info-Befehl. Wenn wir hier info eingeben, können wir eine große Liste an Informationen sehen. Das sind alle Variablen und Instanzvariablen und so weiter, die wir gerade im aktuellen Kontext verfügbar haben.7:11 Wir können also zum Beispiel das hier nehmen. Wir können at generated associated methods nehmen, richtig? Wir können das kopieren, und das verweist auf ein Objekt hier, wo die verfügbaren Methoden in diesem Objekt sind. Wir können also sagen at generated associated methods dot methods dot sort, zum Beispiel, und bevor ich das ausführe, lösche ich einfach die Konsole, Enter drücken.7:34 Und jetzt sehen wir alle verfügbaren Methoden in diesem Objekt dort, richtig? Das ist wirklich cool. Und wieder, wenn Sie vergessen, wo Sie sind, während Sie experimentieren oder was auch immer. Erinnern Sie sich an whereami? Und Sie können sehen, wo Sie sich gerade befinden.7:46 Jetzt, wo wir unseren Kontext zurückhaben, schauen wir uns einen weiteren verfügbaren Befehl an. Den step-Befehl. Schauen wir uns hier die Dokumentation an, der step-Befehl – Sie können step allein sagen oder ihm eine Nummer geben. Und der step-Befehl erlaubt es Ihnen, in den Code einzusteigen. Ich denke daran wie an das Einsteigen in die Ausführungspunkte im gesamten Programm.8:13 Sie können also step machen, wissen Sie, nur einen Schritt, mehrere Schritte, und kommen zum nächsten, wie sie hier sagen, nächsten unterbrechbaren Punkt. Wenn wir dort, wo wir gerade sind, ein step machen – gerade sind wir bei Zeile 18 hier. Wenn wir step ohne Nummer sagen, sehen wir, dass wir zur nächsten Zeile hier steppen, aber wir beginnen am Anfang der Zeile hier. Gerade jetzt wurde diese aktuelle Methode also noch nicht aufgerufen, und auch die andere Hälfte dieser Bedingung wurde noch nicht ausgeführt. Wir sind also quasi am Anfang dieser Zeile hier, bevor irgendetwas anderes passiert.8:50 Wenn wir jetzt nochmal step machen, sehen wir, dass wir jetzt in der current-Methode landen, okay? Wir haben also ein step gemacht, wir waren genau hier. Auf Zeile 19, am Anfang hier, steppen wir in diesen Aufruf hier zu current hinein. Es steppt also quasi zu diesem nächsten Ausführungspunkt, so denke ich darüber. Jetzt sind wir also hier, richtig?9:12 Und Sie können hier Dinge tun und mit diesem Code herumspielen, wenn Sie wollen, wissen Sie, Sie können einfach sehen, was first up publish Ihnen gibt, bevor Sie diesen order und so weiter aufrufen, richtig? Was hier jetzt Spaß macht, ist, dass wenn Sie an einem bestimmten Punkt weiter steppen, zumindest in diesem Fall hier beim Aufrufen dieser Klassenmethoden hier, wenn wir nochmal steppen, sehen wir, dass wir jetzt in den Quellcode für Active Record scoping named.rb hinabgestiegen sind, richtig? Jetzt sind wir also innerhalb von Rails-Quellcode hier, in den wir durch die Verwendung von debug und dem step-Befehl gesteppt sind, um durch die Ausführung oder die unterbrechbaren Punkte, wie sie im Code sagen, zu navigieren. Sie können diese Reise also fortsetzen und step und step machen, und es wird einfach weiter zu den nächsten unterbrechbaren Punkten gehen, dem nächsten Punkt und so weiter, wenn Sie möchten, mit Ihrem Programm fortfahren, aufhören zu steppen und stattdessen zum nächsten gesetzten Breakpoint fortfahren, wenn er im Ausführungspfad hier liegt, oder einfach Ihr Programm fortsetzen, und wenn es keine weiteren Breakpoints gibt, einfach bis zum Ende laufen – Sie können continue oder kurz con eingeben, aber ich mache hier einfach die lange Form, continue, wir drücken continue und dann sehen wir, dass unser Programm ganz durchläuft, es holt sich dieses latest event, und wir sind jetzt zurück in der IRB-Sitzung, wir sind also aus der Debug-Sitzung herausgekommen und sind jetzt zurück in der IRB-Sitzung. Ich verlasse also die IRB-Sitzung hier und springe zurück in die Konsole und lassen Sie uns unseren Breakpoint nochmal erreichen und uns ein paar andere Dinge ansehen.10:49 Hier sind wir also wieder, zurück an unserem Breakpoint, es gibt auch den next-Befehl. Wenn wir uns dort die Dokumentation für next ansehen, im Gegensatz zu step, wo es hineinsteppt, springt next darüber und setzt das Programm bis zur nächsten Zeile fort. Schauen wir uns an, was passiert, wenn wir hier next benutzen. Wir sind gerade auf Zeile 18 hier, wenn wir zu next steppen, sehen wir, dass wir auf der nächsten Zeile sind. Okay, das war ähnlich zu dem, was wir mit step gemacht haben, richtig?11:18 Wir gehen also genau hier zum nächsten Punkt, richtig, zum nächsten unterbrechbaren Punkt, und wir sind am Anfang hier, current wurde nicht aufgerufen, auch previous nicht, aber während wir letztes Mal bei step in der current-Methode gelandet sind, schauen wir, was passiert, wenn wir hier next drücken. Wir sehen hier also, dass es darübergesprungen ist, richtig? Diese gesamte Zeile hier, es hat diese Codezeile ausgeführt und ist dann zur nächsten Zeile gesprungen. Wir haben also nicht all die schönen Details, wenn man so will, der current-Methode gesehen und dann in Active Record, richtig? Wir sind über diese gesamte Zeile gesprungen, sie hat ihre Sache gemacht, und jetzt sind wir auf der nächsten Zeile, die für uns zufällig das Ende dieser Methodendefinition hier ist.12:05 Alles klar, ich verlasse also diese Sitzung, und dann springe ich zurück in unsere Rails-Konsole hier, und ich erreiche unseren Breakpoint nochmal, indem ich event.latest aufrufe, okay. Und jetzt haben wir binding.irb benutzt und sind dann in die Ruby-debug-Sitzung gelangt, indem wir Befehle aus dem Ruby-debug-Gem aufgerufen haben. Das ist also ein Weg, dorthin zu gelangen. Wenn Sie binding.irb benutzen und dann einen der Befehle aus debug aufrufen, wird das den Befehl automatisch ausführen und Sie in diese Debug-Sitzung versetzen und diesen Befehl ausführen, den Sie benutzt haben. Wenn Sie keinen Befehl ausführen wollen und einfach in die Debug-Sitzung gelangen möchten, können Sie einfach debug eingeben, okay.12:52 Und das bringt Sie in die Debug-Sitzung. Und wenn Sie whereami eingeben, sehen Sie, dass Sie immer noch an derselben Stelle im Code sind, richtig? Wir sind genau hier. Zusätzlich sehen wir hier eine Liste einiger Frames, und wir kommen gleich zu Frames. Aber so gelangen Sie in den Debugger, durch das Ruby-debug-Gem, über IRB oder binding.irb.13:19 Alternativ, wenn wir hier herausgehen, haben wir ein paar andere Optionen. Wir können also auch binding.b machen, okay. Und wenn wir wieder in unsere Konsole springen, unsere Rails-Konsole, und wir erreichen diesen von binding.b erstellten Breakpoint, sehen wir, dass wir direkt in eine Debug-Sitzung fallen. Wir überspringen den IRB-Teil und gehen direkt in den Debugger. Das ist also eine Methode, die aus dem debug-Gem kommt.13:46 Das ist eine Kurzform von binding.break. Sie können also binding.break, das vollständige Wort break hier, eintippen, oder Sie können einfach binding.b als Kurzform benutzen. Das ist also ein Weg, direkt in die Debugger-Sitzung zu gelangen, ohne binding.irb machen zu müssen. Aber wenn binding.irb die schwer abzulegende Gewohnheit ist – wenn Sie das debug-Gem in Ihrer Anwendung haben, können Sie trotzdem darüber hineingelangen, über binding.irb.14:11 Schauen wir uns schnell einen anderen Weg an, hineinzukommen. Wir können also bind dot IRB machen, binding.b, und so weiter, das andere, was wir tun können, ist debugger aufzurufen, genau so, okay. Wenn wir jetzt zurück in unsere Rails-Konsole springen und dann event.latest machen, sehen wir, dass wir dann den debugger erreichen, und wir landen wieder direkt in einer Debug-Sitzung. Das sind also Ihre Wege, in das debug-Gem zu gelangen, richtig? Schauen wir uns jetzt den break-Befehl an, denn der ist wirklich cool.14:46 Mit dem break-Befehl allein – er ist auch B als Kurzform, aber ich benutze hier die lange Form. break allein, wenn Sie darauf Enter drücken, gibt Ihnen eine Liste aller gesetzten Breakpoints zurück, falls Sie welche gesetzt haben. Wir haben gerade keine. Aber eine coole Sache hier ist, dass Sie zusätzliche Breakpoints innerhalb dieser Sitzung hier setzen können, richtig? Sagen wir also, wir wollten einen Breakpoint nach Zeile 22 hier hinzufügen, okay?15:15 Auf Zeile 23 wollen wir also einen Breakpoint hinzufügen. Was wir also tun können, ist break oder B zu sagen und dann einfach 23, okay? Und jetzt sehen Sie, dass wir diese Ausgabe hier bekommen, Breakpoint-Zeile, und in welcher Datei es war, und dann welche Zeile, okay? Wenn wir jetzt hier den break-Befehl eintippen, sehen wir dieselbe Ausgabe. Wir haben also jetzt einen Breakpoint gesetzt.15:37 Und jetzt, wenn wir direkt von hier aus springen wollen – solange der nächste Breakpoint, den wir gesetzt haben, im Ausführungspfad unseres Programms liegt – können wir continue eingeben, okay? Und es wird von dort ausführen, wo wir gerade in unserem Programm sind, aktuell auf Zeile 18 hier, wo dieser debugger gesetzt wurde, und es wird durch unser Programm laufen, bis wir einen weiteren Breakpoint erreichen, was in unserem Fall passieren wird, weil wir in der nächsten Zeile hier current aufrufen und wir einen Breakpoint innerhalb dieser Methode auf Zeile 23 gesetzt haben. Wir drücken hier continue. Wir sehen, dass der Code ganz durchläuft und genau am Anfang von Zeile 23 hier in current anhält. Das ist also wirklich cool.16:16 Sie können also zusätzliche Breakpoints setzen und sie erreichen, solange sie im Ausführungspfad liegen, Sie können weiter zu ihnen fortfahren und sie treffen und nach Bedarf hinzufügen, ohne diese Sitzung verlassen zu müssen, zurück zu Ihrem Quellcode zu gehen, einen neuen Breakpoint dort zu setzen, wo Sie wollen, alles neu auszuführen, sie wieder alle zu treffen und so weiter. Sie können einfach im selben Kontext bleiben, wissen Sie, Ihren Fokus nicht unterbrechen, und etwas durcharbeiten, um es zu debuggen. Sie sind auch nicht darauf beschränkt, zusätzliche Breakpoints in der aktuellen Datei zu setzen, in der Sie sich befinden. Schauen wir uns das als Nächstes an. Alles klar, sagen wir, wir debuggen etwas rund um diesen Methodenaufruf hier, diese full-Methode, richtig?16:56 Irgendetwas passiert, wir wissen nicht so genau, was, wir wollen einfach einen debugger hier treffen und anfangen, das Ding zu debuggen, richtig? Wir setzen dort also einen debugger und springen dann hier in unsere Rails-Konsole, und dann sagen wir einfach team gleich team.first, um hier anzufangen, und dann sagen wir einfach team.full, Fragezeichen, richtig? Und wir erreichen unseren debugger-Breakpoint, wir sind gerade in einer Debugger-Sitzung, richtig? Und jetzt wollen wir hinzufügen – wir sehen, dass sie diese at-or-above-capacity-Methode auf team users aufrufen. Was wir jetzt also tun können: Wenn wir wissen, dass das in der team-user-Datei ist, wissen wir aber nicht, auf welcher Zeile – wenn wir wüssten, auf welcher Zeile es ist, könnten wir Folgendes tun, und ich weiß hier drüben einfach, dass es Zeile 16 ist, ich habe schon nachgeschaut, zurück hier – eine Sache, die wir tun können, ist, dieser Datei und dieser Zeile einen Breakpoint hinzuzufügen, wir könnten also break sagen, und dann müssen wir den Pfad zur Datei übergeben, das wird lang, also haben Sie Nachsicht, vielleicht spule ich hier vor, app, models, team, user, und dann Doppelpunkt 16, okay?18:02 Wir haben also dieser Datei und dieser Zeile einen Breakpoint hinzugefügt, und wenn wir jetzt continue oder kurz cont, C-O-N-T, eintippen und Enter drücken, sehen wir, dass unser Programm weiterläuft, bis wir zu diesem Breakpoint gelangen, den wir hier gesetzt haben, richtig? Jetzt hätten wir wahrscheinlich step benutzen können, um durch das alles zu steppen und auch hierher zu gelangen, aber ich wollte nur ein Beispiel zeigen, wie man Breakpoints in anderen Dateien setzen kann. Eine coole Sache, die Sie hier tun können, ist, dass Sie statt diesem Pfad hier und der Übergabe einer Zeilennummer einfach die Klasse und die Methode übergeben und so einen Breakpoint setzen können. Schauen wir uns schnell an, wie das geht. Alles klar, zurück, wir springen hier in eine andere Rails-Konsolensitzung, sagen wir nochmal team gleich team.first, okay? Und dann sagen wir team.full, wir treffen das, einen debugger-Breakpoint, und jetzt wollen wir von dort, wo wir gerade sind, einen Breakpoint auf dieser Methode drüben in der team-user-Klassendatei setzen.19:05 Wir könnten das also tun, wie wir gesehen haben, indem wir den Pfad zu dieser Datei und die Zeilennummer übergeben, aber sagen wir, wir kennen die Zeilennummer nicht, und wir wollen nicht zurück zu unserem Editor gehen, diese Datei öffnen und den Breakpoint dort hinzufügen, denn wenn wir das ohnehin tun, könnten wir auch einfach debugger hinzufügen, während wir genau dort sind, und den gesamten Prozess neu starten, aber wir versuchen, unseren Kontext hier zu behalten und unseren Fokus auf das, was wir gerade tun, nicht zu verlieren. Wir wollen im Fluss bleiben und auf dem Weg weiter voranschreiten, um etwas hier zu debuggen. Was wir hier also tun können, wenn wir die Zeilennummer nicht wissen, ist, gegen die Klasse und den Methodennamen zu matchen. Da dies eine Klassenmethode hier auf team user ist, können wir einfach sagen break on team user dot at or above capacity, Fragezeichen, okay, und dann können wir dort Enter drücken, und wir sehen, dass dieser Breakpoint auf einer Methode aufgerufen wurde und dass er der team-user-Datei auf Zeile 16 hinzugefügt wurde, richtig, und wie wir vorher gesehen haben, war das genau die Zeile, auf der diese Methode definiert ist. Wenn wir jetzt hier continue oder kurz cont, C-O-N-T eingeben, wenn wir Enter drücken, wird unser Programm weiterlaufen, bis es diesen nächsten Breakpoint erreicht.20:26 Das tun wir also, und wir sehen, da sind wir. Wir sind hier am Anfang dieser Methode. Wir sind innerhalb des Methodenkörpers, am Anfang dieser Zeile. Alles klar, lassen Sie uns dieses Video abschließen, indem wir uns Frames ansehen, okay. Ich bin also wieder in der Rails-Konsole hier.20:39 Ich habe mir das erste team geholt. Ich rufe einfach team.full auf, damit wir wieder unseren Breakpoint treffen. Okay, jetzt sind wir in einer Debugger-Sitzung. Was wir also tun können, wie Sie genau hier sehen können, es zeigt uns die ersten zwei Frames hier, und dann sagt es in 27 Frames, und dann sagt es, benutzen Sie BT für alle Frames. Der BT-Befehl listet also alle Frames auf, auf die wir gerade Zugriff haben.21:06 Ich schaffe hier also etwas Platz im Terminal, und dann führen wir diesen BT-Befehl aus und schauen, was wir dort bekommen. Auch BT ist einfach die Kurzform für back trace. Wie Sie hier sehen können, bekommen wir eine automatische Vervollständigung. Sie können also entweder das volle back trace eintippen oder BT, um diese Liste hier zu bekommen. Und was wir hier sehen, wenn wir diesen Befehl ausführen, ist eine Liste aller Frames, die wir gerade haben.21:31 Es ist im Wesentlichen ein Stack Trace hier, richtig? Das hier ist also der Frame, in dem wir uns befinden, in dem wir unseren Breakpoint erreicht haben. Und das ist alles, was passiert ist, bevor wir diesen Breakpoint erreicht haben, okay? Was wir hier also tun können, ist, diese Kennungen oder ID-Nummern hier am Anfang zu benutzen, die, wissen Sie, Raute null, Raute eins, oder Hash eins, Hash zwei. Wir können diese benutzen, um direkt zu einem Frame zu springen, oder wir können Schritt für Schritt gehen.22:03 Der Weg dahin – das wird ein bisschen seltsam sein. Wenn wir uns diese Liste ansehen, würden wir denken, dass wir hier hinunter wollen, aber eigentlich wollen Sie den up-Befehl benutzen, um einen Frame nach oben zu gehen, und stellen Sie sich einfach vor, welcher aktuelle Frame Sie auch immer gerade sind, up wird ihn zur, wissen Sie, nächstgrößeren Nummer erhöhen, okay? Wenn wir also hier sind und zu main gehen wollen, können wir einfach den up-Befehl eintippen. Und jetzt sehen wir, dass unser aktueller Frame genau hier main ist. Wenn wir hier L oder list eintippen, sehen wir etwas Quellcode für den aktuellen Frame, okay?22:39 Wenn wir jetzt zurück zu dem Frame gehen wollen, von dem wir gerade gekommen sind, können wir down eintippen. Wenn wir also nach unten gehen, sehen wir, dass wir jetzt wieder hier bei diesem Frame sind, und wieder können wir list eintippen, um den Quellcode zu sehen, und wir sehen hier den Quellcode für diesen aktuellen Frame. Zusätzlich können wir auch zu einem bestimmten Frame springen. Zum Beispiel, wenn wir zu diesem Frame hier gehen wollen, Frame 12, können wir entweder F und dann die Kennungsnummer eintippen, die in unserem Fall 12 ist, oder den vollständigen Befehl, der frame ist, und dann 12, okay? Und jetzt sehen wir, dass wir in Frame 12 sind, und das ist diese IRB-Datei hier.23:23 Und wenn wir L oder list eintippen, können wir den Quellcode für diesen Frame hier sehen. Das ist also ein wirklich cooles Feature. Es erlaubt Ihnen, den Stack Trace nach oben und unten zu gehen und Dinge in verschiedenen Frame-Kontexten anzuschauen. Und wieder, sobald Sie in einem Frame sind, können Sie list eintippen, wie ich es die ganze Zeit getan habe, um den Quellcode zu sehen. Sie können auch info eintippen, um die verfügbaren, wissen Sie, lokalen Variablen, Instanzvariablen und andere Dinge zu sehen, die Sie in diesem Kontext verfügbar haben.23:52 Das ist also auch wirklich cool. Wissen Sie, info ist großartig. Es gibt auch einige Argumente, die Sie dem info-Befehl übergeben können. Mehr Informationen dazu finden Sie im Readme des debug-Gems. Aber zum Beispiel können Sie info locals sagen, und es gibt Ihnen nur die lokalen Variablen zurück und nicht all das andere.24:14 Eine letzte Sache: Wenn Sie in der Debug-Sitzung sind und sich nicht an Befehle erinnern können oder was Sie hier tun können, gibt es eine help-Option. Sie können einfach help eingeben, und es gibt Ihnen eine Liste aller verfügbaren Befehle, die Sie hier in der Debug-Sitzung haben, mit ein paar netten kleinen Überschriften, die die verschiedenen Abschnitte von Befehlen trennen, Breakpoint-Befehle, Kontrollfluss-Befehle und so weiter. Und zusätzlich, wie Sie hier sehen, können Sie einfach help eintippen, um die vollständige Liste zu bekommen, oder help und dann einen Befehl, um Hilfe nur für diesen Befehl zu bekommen. Zum Beispiel sagen wir vielleicht help back trace, richtig? Und dann sehen wir die Informationen für alle back-trace-Befehle.24:53 Damit werde ich dieses Video hier abschließen. Ich hoffe, dass Sie dadurch ein paar neue Dinge kennengelernt haben, neue Werkzeuge, die Sie nutzen können und die Ihnen zur Verfügung stehen, um Ihnen besser beim Debuggen von Anwendungsfehlern zu helfen. Auch das war eher ein einführender Ansatz zu diesem Gem, es gibt noch viel mehr im Readme zu lesen, viele mächtige Dinge hier. Meine Hoffnung ist, zitieren Sie mich nicht dabei, aber ich versuche es – mein Ziel ist es, ein Folgevideo hier zu machen, hoffentlich mit jemandem von den Maintainern dieses Gems, und zu sehen, ob wir zu zweit ein Video machen und tiefer in einige der fortgeschritteneren Nutzungen dieses Gems eintauchen und diese nächste Stufe des Debuggens bieten können.25:47 Wir werden also sehen, was dort passiert. Ich werde mein Bestes versuchen, jemanden vom Team hier zu bekommen, der mit mir in einem Videoanruf mitmacht und tiefer in diese Sachen eintaucht, aber unabhängig davon, nutzen Sie dieses Gem unbedingt. Es ist großartig, es ist wirklich mächtig. Und ja, damit verlasse ich Sie hier, und happy debugging.

​
Über dieses Tutorial

Dieses Tutorial fasst einen GoRails-Screencast über das Debugging mit Rubys debug-Gem zusammen, präsentiert von Collin. Der Screencast ist das Originalwerk. GoRails veröffentlicht ihn, und den Rest der Serie, auf gorails.com.