To start debugging in ruby 1.9, you need the gem
debugger (see github
You can also do it in one shot:
Because the breakpoint is in your code, you can put logic around it
You should put
debugger before the desired breakpoint because it will stop on
the next statement after a call to
debugger. If you put it at the end of
function, you may end up in a different file, wherever the stack frame happen
to be after the function returns.
You run your code the same way as you did before, the difference is that you’ll be placed into a interactive ruby debugger.
People have injected
pry into their code to put an interactive shell so they
can look around (This is done by
require "pry" and calling
pry is powerful and it can be used for some types of debugging,
but it’s not a debugger. You are not able to step through your code. Within
debugger, have access to the ruby interpreter so you have most of the
functionality you need. So if you used
pry in the past, you should try out
Once you’re inside the debugger, you can type “help” or just “h”.
You can also type “h set” to see options available
You can put these commands into a
.rdebugrc file. You can also require ruby
files so it’ll load automatically when the debugger is run. I always have
“autolist” set so I can see the code listing while I am stepping through the
code. You should also set autoeval so you can type ruby code (e.g. “a = 2”)
rather than typing “eval” (e.g. “eval a = 2”) or using “p” to print the value.
Some useful commands
- n : to go to the next statement
- s : to step into the statement
- c : continue
- fin : to finish the method and stop at the next stack trace
: print out result of ruby expression
: pretty print result of ruby expression. It prints list and hashes in a more readable format
- bt : a backtrace to tell you where you are (you can also use “where”)
You can exit by typing “exit”, “q”, or press Ctrl-d.
When you’re debugging something complicated, it’s a good idea to put some print
statements to see what your program is doing, but you may not want to have to
clean it up every time. I solve this by creating a
Logger class that takes a
debug method. It will only print if the debug flag is set. This is
especially useful when you’re dealing with multiple threads or when you’re not
sure where to put the breakpoint.
I think you should try
debugger out. It’s worth learning.