Debugging Ruby with Byebug and Pry

Direct Answer

Byebug pauses a running Ruby program and lets you inspect the current stack frame, set breakpoints, step into or over calls, and continue execution. Pry is an interactive Ruby console that can open at a specific binding, so binding.pry exposes the local variables and methods available at that line. The pry-byebug extension adds stepping and stack navigation to Pry. Put a breakpoint just before the value becomes wrong, reproduce the smallest failing case, inspect inputs before changing them, and remove temporary breakpoints before committing. On modern Rails, also know that the bundled debug gem is the current default debugger.

Deep Dive & Architecture

Interactive debugging is most effective after the problem has a stable reproduction. A breakpoint placed at a random controller line exposes a great deal of state but no clear question. Instead, identify the last value known to be correct and stop just before the next operation. The session then tests a concrete hypothesis: whether the caller supplied bad input, the callee transformed it incorrectly, or a side effect changed shared state.

At a stop, the debugger selects one stack frame. Expressions typed at the prompt are evaluated in that frame's context, so they can read locals and instance variables visible there. next advances without descending into ordinary calls; step follows a call into its implementation; finish returns to the caller; stack commands reveal how execution reached the point. Changing a variable can be useful for an experiment, but the observation should be repeated from a clean run before treating it as evidence.

Pry focuses on understanding the runtime object model. binding.pry pauses within a particular lexical and object context, ls lists reachable methods and variables, and show-source finds Ruby method source when available. Adding pry-byebug supplies breakpoints, frame movement, and execution controls. Command names and aliases can differ by tool version, so help is safer than relying on a remembered single-letter alias.

A Rails request paused in a terminal has not completed. The browser may appear to hang, database locks may remain open, and another request can observe partial conditions depending on transaction boundaries. That is acceptable in a local environment and dangerous in a shared one. Remote production debugging also exposes application data and execution control, so logs, traces, metrics, safe console procedures, or a reproduced test are the normal production tools.

Current Rails-generated CRuby applications include the debug gem in development and test. It uses entry points such as debugger and binding.break and supports modern debugging features. Byebug and Pry remain common in existing projects, which is why a developer should understand their roles, but the project's Gemfile and runtime decide the actual tool rather than a tutorial's age.

The outcome of a session should be durable knowledge. Once the first incorrect state transition is found, explain why the previous tests allowed it, implement the smallest repair, and add an example that fails without the fix. Delete the breakpoint and any secret-bearing scratch output. A debugger shortens investigation; it does not replace a specification or regression test.

Code Example

class Invoice
  def initialize(subtotal, discount)
    @subtotal = subtotal
    @discount = discount
  end

  def total
    # binding.pry # inspect @subtotal, then step into apply
    @discount.apply(@subtotal)
  end
end

# Byebug alternative in a configured project:
# byebug
# subtotal_after_discount = @discount.apply(@subtotal)

Common Mistakes & Pitfalls

Leaving byebug/binding.pry in committed code (pauses production), or debugging with puts everywhere (use a debugger).