The Developer tools I really love are those that help me reduce the time that elapses between a bug occurring and a bug being fixed.
One of the more obvious types of bug is a top-level unhandled exception. The message “I’m sorry, something went wrong” is how these manifest themselves on real-world sites. But during development, most languages and web frameworks will give you something better – you’ll probably get a page with a reasonably formatted stack trace. It’ll probably have line numbers and file names in the trace entries. It might even have some contextual data, but that’s usually about it.
And that’s just not good enough.
A stack trace is a reasonable start when debugging – it’s a decent signpost towards the error in your application – but we can do much better, especially in a rails webapp. With that in mind, let’s look at two different ways to improve the default experience of unhandled exceptions in development in your rails app:
1. Command-line nirvana
pry-rescue captures unhandled exceptions and opens a pry session at the exact line that an exception was raised. Let’s give it a try. Make sure these two gems are in the development group of your app’s Gemfile:
group :development do gem 'pry-rescue' gem 'jazz-hands' # includes a collection of pry plugins end
Then run bundle install followed by rails console to see your new, shinier console. If everything works normally, try running your server with pry-rescue enabled by running:
rescue rails server
Now use your browser to load any page that’s guaranteed to raise an exception. (You might need to add an explicit “raise ‘just for fun!’” line to one of your controller actions). Now go back to the command-line that you ran the server from and you should see a nice colorful prompt just waiting to help you debug the error!
You can get more insights by typing ls to see all the controller methods that are in scope, some of which will help to debug the error. If you want to kill the server use the exit! command. If you want to finish the request (so you can reload the page), type quit. For additional insights on how to use pry, try its built-in help command and check out one of the great talks by Conrad Irwin, the author of pry-rescue, such as Efficient Debugging with Pry or Pry: The Good Parts.
Making it automatic
The above is a huge productivity booster, but your habit for running your rails apps probably doesn’t involve prepending rescue every time you need to start your local server. Without the rescue command, you’ll only get the usual rails error page. Instead we need to make the pry-rescue functionality activate automatically.
Thankfully pry-rescue has a hook to help us do that. Create a new file named config/initializers/pry_rescue.rb and add the following line to it:
Pry.enable_rescuing! if Rails.env.development?
Now start your rails server in the usual manner using rails server and pry-rescue will automatically activate in development whenever an unhandled exception occurs.
NOTE: when pry-rescue activates, the console it gives you will block rails from outputting the usual error page. This can be a little confusing if your terminal window is hidden underneath your browser window — in the heat of development I sometimes forget why a page is seemingly taking forever to load — in fact it’s waiting on input from the pry-rescue session! A useful workaround to minimize confusion is to ensure at least a little of your terminal app is visible when you’re in the browser.
2. Putting the REPL on the error page
Instead of having to remember to switch to the console, wouldn’t it be great if there was a way to embed a ruby console on the error page that rails serves up? That’s exactly what the better_errors gem does.
Remove the pry-rescue line from your Gemfile and delete the config/initializers/pry_rescue.rb. Now add the better_errors gem to your Gemfile:
group :development do gem 'better_errors' gem 'jazz_hands' end
Create a new file, config/initializers/better_errors.rb and add the following lines to it:
if Rails.env.development?
BetterErrors.use_pry!
AwesomePrint.defaults = {plain: true}
end
Now restart your rails server and browse to the action that raises an error. You should immediately see a REPL in your browser, complete with the full power of pry!
Why bother?
Although it takes a bit of setup work, both of these tools will save you more time than the setup work in the first week alone.
The key to great productivity when building new features is to fix defects faster. If you’re already fixing them fast, get hold of tools that helps you fix them even faster still. The quicker we can get to working code, the quicker we can get to reliable, shippable code!
The immediacy of better_errors is hard to beat, but the power and ease of use of pry-rescue on the command-line is hard to replicate directly in the browser. Choose your favorite of the two methods and try it out for a week. You won’t be disappointed.
What are your Pro tips for fixing errors faster? Is there an equivalent to pry-rescue for front-end development? Let me know in the comments below.
Follow @LeeMallabone to follow my posts about front-end development; tools, tips and cutting-edge UI hacks.
