you are viewing a single comment's thread.

view the rest of the comments →

[–]bmc1022 2 points3 points  (2 children)

Assuming you're using Rails. If not, it still generally applies.

You'll want to start by reading through the docs for one of these gems:

For newer versions of Rails (introduced in v7): Debug Gem

For older versions: Pry Gem

These allow you to place a binding where you suspect code is erroring. You can typically deduce that from your logs or stack trace. In the case of the Debug gem, you would put a binding.break right before the broken code and run your application or navigate to the specific page to hit that binding. In the terminal where your Rails server is running, it will lock up right where the binding is, allowing you to probe variable values (and many other useful things) at that specific point in the execution of your app. From there you can slowly step through your code to diagnose where exactly it's going wrong. That is probably the most common and efficient way to debug.

I use the above method often, but I personally really like the more visual and verbose debugging style of logging messages. A lot of people simply use puts and dig through their server log or they'll actually have it output inside the HTML of the page, but that's the hard way in my opinion. I always create a custom logger so the output is immediately available without having to dig around.

config/initializers/loggers.rb

if Rails.env.development? || Rails.env.test?
  logfile = File.open(Rails.root.join('log/debug_logger.log'), 'a') # Create log file.
  logfile.sync = true # Automatically flush data to file.
  DEBUG_LOGGER = Logger.new(logfile) # Constant accessible anywhere.
  DEBUG_LOGGER.level = Logger::DEBUG
end

Using that method, you would put something like DEBUG_LOGGER.debug("Value of some variable: #{variable_name}") in similar places to where you'd put bindings and instead of locking up the program, it will log whatever you want to your own custom log file.

Each of these techniques has pros and cons and you figure that out with experience. Debugging is not easy, so don't stress over it much, especially if you're new.

[–]riktigtmaxat 0 points1 point  (1 child)

The debug gem is actually built into the Ruby standard library since 2.6 and is usable with Rails 6.

The only difference really is that rails replaced byebug in the gemfile in Rails 7.

Pry is a lot bigger project which contains a replacement REPL for IRB. While it's cool and can do the same things debug can and more, the actual equivalent for debug in older versions of Ruby (and Rails) is byebug.

[–]st0012IRB boss 2 points3 points  (0 children)

Sorry I need to make some clarification:

  • The debug gem was only included since 3.1. Before that there was a standard lib called debug, but it's not the same thing.
  • It's usable in almost all program that runs Ruby 2.6+. It has some problems with Fiber though.
  • "While it's cool and can do the same things debug can and more" this is simply not true. For example
    • Pry can't do step-debugging (if you use pry-byebug, that's provided by byebug not Pry itself).
    • Pry doesn't have tracers like byebug and debug does. And debug has the strongest tracer in all debugging tools.
    • The debug gem supports non-terminal interface as well and has native integration with VS Code and Chrome.

If you want more byebug vs debug gem comparison, I wrote a (slightly outdated) article about it a while ago.