Debugging tips in Ruby on Rails

Posted on 27 September 2006

There are quite a few different ways to go about analysing application errors in Ruby on Rails. I know when I first started out I found the error messages were quite cryptic.

On a typical application error there are three grey boxes. The first tells you the name of the error that ocurred.

The second shows the extracted source i.e. the line of code causing the error.

The third box tells you exactly where that line of code can be found. The key is to look past the lines beginning C:/ruby/lib/ruby/gems/ and look for the first one that begins with #{RAILS_ROOT}. It will tell you the exact file and line number you should be looking at.

Output to the console

Outputing to the console is useful for quickly testing to see your code is running as you expect. Literally just use:

puts "bla"

Output to the log

You can also output to the log. Sometimes outputting a variable can help. For example:

logger.info("bla: #{@object.name}")

Debug an object on the page

A useful way to check what an object contains is to output it in your view. Just use the following line:

debug @object

This will show every method available to the object wrapped in a <pre> tag.

Tail the log

Tailing the log file means that when you load the page, the console will output detailed information on every line of code that is run, including all SQL queries exactly how they are executed.

In Radrails you can literally right click on the log file and select tail. View the console and the tail view should be automatically selected. Note that clearing the log in the console view doesn't empty the file.

For linux/mac just open up your console, navigate to the log folder and use the following line:

tail -f development.log

Using Ruby irb

irb is a Ruby module that lets you enter Ruby programs interactively and see the results immediately.

It's great for testing code in an environment independant of your application. To use it, type the following at the command line:

script/console

Using breakpoint

Arguably one of the most under-used features in Rails and it has to be one of the best debugging tools. Using breakpoint gives you an irb prompt at the exact point in your code where you placed the breakpoint.

Simply place the word breakpoint in your code before the error. Now open the console and type:

script/breakpointer

Refresh your page with the error and in the console, after a few seconds, the prompt will be available.

Essentially you can now test your code, exactly as it is in your file. For more detailed instructions check the Rails wiki article on breakpoint

Debugging in production mode

By default production mode just shows an ugly application error page with no debug information. One way to get round this is to tell Rails your IP and then you will get the same output as you do on localhost. Just use:

protected
 def local_request?
   ["127.0.0.1", "your.ip"].include?(request.remote_ip)
 end

Using this method still shows ugly error messages to your users. Which leads me on to the Exception Notification plugin.

Exception notifications

One of the best debugging tools I have come across is the Exception notficiation plugin. Whenever a user manages to come across an aplication error you will receive an email with full details of that error. The level of detail is more than enough to help you decipher what may have happened. Install the plugin using:

ruby script\plugin install exception_notification

You can easily use this plugin to serve up custom friendly error messages to your users.

Note that you should not use the local_request? method I just talked about as this is built in to the plugin and will conflict.

Check out the exception notifier read me for full details on how to tell the plugin your IP so that you get the error printed to the screen and not in an email. This ensures you get error messages, while your users get custom, error friendly, pages.

View the snippets archive ››