My favorite debugging resource is a little book called Debugging, available from Amazon. It contains 9 rules that cover any situation where you have to find and fix a problem, but of course, it specializes in software debugging. Info about the book, including a poster that lists the 9 rules, is available at http://debuggingrules.com.
Most of the time using print statements seems to be the fastest way to debug things, however sometimes it really is worth rewriting part of the code if the error just seems to make no sense. A few times I accidentally used ‘=’ instead of ‘==’ and that is one of the simplest errors that cause cause a lot of wasted time.
Here’s one for when you’re really stuck tracking down why a test or web request fails. I had to use this for figuring out an very hard to debug Rails 3 to Rails 4 migration bug. I’ll use RAILS_3 and RAILS_4 to distinguish between the two branches of code that I’m debugging.
Be able to reproduce the passing operation on RAILS_3 and see the failure on RAILS_4.
Clear out the logs on both both envs with rake log:clear
Set both envs to have logging set to :debug. Be sure that you can see the SQL being logged.
Run both branches, and save the log results of running both (and only the single operations) to 2 text files, which we’ll call rails_3.log and rails_4.log.
Open those files up in your text editor and search and replace using this regexp to strip out the leading timestamps: ^\[.*\]. This filters out messages like this:
Depending on how you’re doing logging, you might need a different regexp. The key is to strip out anything that causes every line to differ.
6. Then use your favorite diff tool to compare the files. I use ediff within spacemacs. Any good diff tool should work.
And then you’ll be able to see some very interesting details regarding where your positive case differs from the failing case.
I’ve resorted to this when using the awesome pry debugging tools fails to help me successfully dive deep inside of the Rails save process.
Here’s my overall order of debugging:
Print statements (see above tips), especially “fenced debug statements”.
Examining the failing log file in addition to what’s on the console.
Using pry especially with my setup, which I’ve shared.