February 20, 2015 by Daniel P. Clark

Some Basic Ruby Tools for Sniffing out Errors

Needing to know what’s going on under the hood is a big part to solving problems and challenges.  For the longest time I only ever used print statements to output to the console the state of something at a specific point.  That’s all I ever used in Python.  But sometimes you need to do a bit more within a specific problem area.

Pry

Pry is an excellent tool that will let you stop the code right where you put it and then give you an irb console to experiment with.  This is helpful for experimenting when something doesn’t work to try and find what does work.  You can learn all about how to use it at: http://pryrepl.org/  Basically to have your program open up an irb shell in the middle of the code you use binding.pry

def my_function(some_args)
  internal_variable ||= some_args

  binding.pry # Stop program here and test local state in an irb session

  :not_evaluated_yet = 8
end

Byebug

I have found that sometimes when calling pry from my Rails project with binding.pry that it doesn’t work.  This lead me to lookup the Rails documentation on debugging and they recommend a gem called Byebug.  It works in a very similar way to pry, but it worked where pry didn’t.  You just put byebug in the code where you would have put binding.pry.  One of my favorite features of Byebug is that you can step through your code in the current scope by typing next and hitting the [enter] key.  You can see more info at: https://github.com/deivid-rodriguez/byebug

pry-byebug

Pry has a lot of addons/pluggins available for it that can improve your debugging/experimenting experience.  pry-byebug is a gem that allows you to combine the best of both worlds of pry and byebug.  See the git repo at: https://github.com/deivid-rodriguez/pry-byebug

Threads

I haven’t branched into the realm of threads much.  But when running tests on a project they each run in their own thread.  Pry and byebug don’t break open with your terminal in this situation.  This I found rather annoying.  I haven’t found the solution to this quite yet, but I have found an equivalent solution as printing current state to the command line.  I use system alert messages to print out whatever variables I need to know.  On my Ubuntu box the command to send messages is notify-send.  So wherever I want I put in back-ticks to run a system command and put my string in.

`notify-send “My custom message #{my_var_1} and #{my_var_2}.”`

This queues the messages up to pop up one at a time.  The alert messages are only so many characters; probably between 180 to 300 characters.  I don’t see in the documentation any way to make them longer, but it’s more than enough for me.  The messages may go by too quickly, in that case add a time option with -t <milliseconds> and your good.

So now you have a modern puts test for threads!

better_errors

If you’re using rails than you’re probably already familiar with the better_errors gem.  It will let you see your Rails environments state at the point of when an error was raised.  When used in combination with the binding_of_caller gem you get an interactive irb prompt in the browser where you can test and experiment as you would in irb.  You can check it out at: https://github.com/charliesome/better_errors

Have Suggestions?

I’m sure there are plenty of other tools out there, loggers, messaging services and other thread safe debugging tools.  If you know of any good suggestions then please leave a comment with some detail about it.  It will be most helpful to me and to others who read this.

I hope you enjoyed this!  Please feel free to comment, share, subscribe to my RSS Feed, and follow me on twitter @6ftdan!

God Bless!
-Daniel P. Clark

Image by trpnblies7 via the Creative Commons Attribution-NonCommercial-NoDerivs 2.0 Generic License.

P.S. I found en excellent conference talk on using Pry

#debug#debugging#error#fixing#problem#rails#ruby#solving

Comments

  1. Tema Bolshakov
    February 21, 2015 - 3:37 am

    When I started to use RubyMine IDE it brings me to completley new level of debugging skils. It’s built in debugger is awesome, i even cant compare it with pry or better errors.

    I also use a lot of rspec for debugging. Actually the first step is usually to reproduce error in test environment.

    • Daniel P. Clark
      February 21, 2015 - 4:37 am

      Thanks for sharing!

      RubyMine has great hints and completions built in. I haven’t learned the major features it’s incorporated. Have you gone through some training for the IDE? What are the advantages of the debugger in it?

      • Tema Bolshakov
        February 22, 2015 - 4:11 am

        There is a plugin for rubymine which sujessts hotkeys for things you are doing using mouse. It helps a lot.
        I also pair programmed a lot with collegues which used rubymine and learned from them.

    • banisterfiend
      February 22, 2015 - 12:42 pm

      As far as i can see, the RubyMine debugger is just a standard IDE debugger. It’s very nice if you like graphical debuggers — but that’s pretty much all it is – a graphical layer on top of a standard debugger. Pry on the other hand is a different kettle of fish, it has an emphasis on introspection and exploration rather than just debugging. I am biased — but I much prefer the level of introspection i get from Pry to a standard stepping debugger, though admittedly it’s not as pretty or easy to use an IDE.

      • Daniel P. Clark
        February 22, 2015 - 1:29 pm

        Yeah. Pry is enjoyable to use as you can explore Object layers just like you would an operating system’s directory structure. It’s well designed.

        • banisterfiend
          February 22, 2015 - 10:55 pm

          For the record, Pry is not built on IRB (as your post seems to imply) it’s a REPL written from the ground up and has 0 code in common with IRB 🙂

          • Daniel P. Clark
            February 22, 2015 - 11:04 pm

            Good to know. It didn’t feel like it was without irb, rather it felt inclusive.

  2. jesus castello
    February 21, 2015 - 9:04 am

    When debugging threads you should use “Thread.abort_on_exeption = true”. Otherwise, threads just die silently and you wil miss the errors.

    For debugging rails apps using the rails console can help a lot. To invoke it you just run “rails console” and then you will be able to run code inside your rails project. You can find more programming tips in my blog: http://www.blackbytes.info/?s=ruby

    • Daniel P. Clark
      February 21, 2015 - 5:45 pm

      Thanks for the tip and the link! Rails console is an excellent way to test things out in your Rails environment. Does abort_on_exception bring that thread to the foreground?

      • jesus castello
        February 22, 2015 - 9:48 am

        abort_on_exception kills your app and shows you a stack trace for the thread expection, so it’s useful for debugging but you probably don’t want to have it enabled for a production app.

  3. Charlie Wilkins
    February 25, 2015 - 11:11 am

    pry-remote will let you use pry effectively in a thread context.

    • Daniel P. Clark
      February 26, 2015 - 12:58 am

      Thanks! This will be very helpful to use.

Leave a Reply

Your email address will not be published / Required fields are marked *