My experience with debugging code has come a long way. Many of you probably share in my painful memories of throwing
echo lines into one PHP file after another. Ah, those were the bad old days.
Thankfully, we rarely ever have to resort to that in Ruby. But Ruby does have its own aspects that make debugging tricky. One of the hardest things for a new rubyist to deal with is when the problems go beyond the comfort of your own hand-written code and into the endless abyss of third-party gems. Once you've crawled your way up the stack trace and hit
lib/active_support/how/many/directories/are/there/in/this/gem.rb, many throw their hands up and head to Stack Overflow. But don't click that Ask Question button just yet. Exploring other people's code (especially good code) is one of the most rewarding things you can do as a programmer and as a member of the open source community. So let's get our hands dirty and maybe learn a little something along the way.
One great gem I recommend for any web project is Better Errors. When an exception occurs in your Ruby web app it gives you a great web interface with a irb-like terminal to see into each level of your stack trace. Rails has started to include something similar in recent versions but I still tend to prefer Better Errors, plus it will work on your non-Rails web apps.
Better Errors only triggers on an exception occurs. So if you want to inspect some arbitrary line of code, just add something like
raise 'pry' and Better Errors will kick in.
Warning: Don't ever install
better_errors in your production environment. That's a huge security risk. It should be a development only tool.
Whenever I've got to get to the bottom of some unexpected behavior in my code, the first thing I turn to is Pry. Pry is a great tool. I can't recommend it enough. And even though Rails' new error page and Better Errors can replace it to a certain extent, I still find myself using it often.
Using Pry is simple. Add
gem 'pry' to your
bundle install, and add a
binding.pry line to your code anywhere you want a breakpoint. From there you'll have a command line with the full context of your code at that point in it's execution. You can see and change anything at this point. And when you're done, just type exit and your code will continue on it's merry way.
Using Pry is great, but what happens when you've got to dig beyond your own code. How do you add
binding.pry to third-party code. Well, Bundler has a trick up it's sleeve to help you out.
path option you can
git clone the repository to your filesystem and then change the line in your
git 'gem_name', path: '/path/to/your/cloned/repo/'. Now just add those
binding.pry lines to the cloned repo and you can dig as deep as you want.
When All Else Fails
Sometimes, Pry by itself just isn't enough to get to the bottom of things easily . A quick search for "pry" on rubygems.org will bing up pages of gems that you can use along with Pry to make your life easier. A couple that I've had good luck with and would recommend are pry-stack_explorer and pry-rescue.
- pry-stack_explorer allows you to climb up and down the stack trace to different points in the execution. Which can save you a ton of time compared to moving that
binding.pryline manually and rerunning your code every time you want to poke your head some place new.
- pry-rescue will automatically halt execution when an exception is raised which can sometimes save you from having to
git cloneprojects like I mentioned above.
So those are some of the tools and tricks I've used to get my code to "do what I mean, not what I say". Being comfortable around debugging tools and other people's code is the first step to writing pull requests to other projects. And giving back to open source is something everybody should strive for. Because let's face it, open source has given us our community and our careers. Plus hacking on open code is both fun and rewarding.