Debugging with pry and byebug in Ruby

Introduction

Debugging helps you find and fix mistakes in your code. Pry and Byebug let you pause your program and look inside to understand what is happening.

When your program is not working as expected and you want to see the values of variables step-by-step.

When you want to stop your program at a certain line to check what is going on.

When you want to try out code commands inside your program while it is paused.

When you want to understand why a loop or condition is not behaving correctly.

When you want to learn how your code flows by moving through it slowly.

Syntax

Ruby

require 'pry'

# Insert this line where you want to pause
binding.pry

# For byebug
require 'byebug'

# Insert this line where you want to pause
byebug

Use binding.pry or byebug inside your code where you want to pause.

Make sure you have installed the gems pry and byebug before using them.

Examples

This pauses the program before adding x and y. You can check the values of x and y in the Pry console.

Ruby

require 'pry'

x = 10
y = 20
binding.pry
sum = x + y
puts sum

This pauses inside the greet method so you can see the value of name before printing.

Ruby

require 'byebug'

def greet(name)
  byebug
  puts "Hello, #{name}!"
end

greet('Alice')

Sample Program

This program pauses inside the loop for each number. You can check the value of num before it prints double the number.

Ruby

require 'pry'

numbers = [1, 2, 3]

numbers.each do |num|
  binding.pry
  puts num * 2
end

Important Notes

When the program pauses, you can type variable names to see their values.

Type continue or c to resume the program after pausing.

Use debugging to learn and fix problems step-by-step, not just to find errors.

Summary

Debugging with Pry and Byebug lets you pause and explore your code while it runs.

Insert binding.pry or byebug where you want to stop and check variables.

This helps you understand your code better and fix mistakes easily.

Practice

1. What is the main purpose of using binding.pry or byebug in Ruby code?

easy

A. To pause the program and inspect variables at a specific point

B. To speed up the execution of the program

C. To automatically fix syntax errors

D. To compile Ruby code into machine code

Solution

1. Step 1: Understand the role of debugging tools

   Both binding.pry and byebug are used to pause program execution.

2. Step 2: Inspect variables and program state

   When paused, you can check variable values and program flow to find issues.

3. Final Answer:

   To pause the program and inspect variables at a specific point -> Option A

4. Quick Check:

   Debugging tools pause and inspect = A [OK]

Hint: They pause code to check variables and flow [OK]

Common Mistakes:

• Thinking they speed up code
• Believing they fix errors automatically
• Confusing with code compilation

2. Which of the following is the correct way to insert a breakpoint using Pry in Ruby code?

easy

A. debug.pry

B. breakpoint.pry

C. pry.binding

D. binding.pry

Solution

1. Step 1: Recall Pry syntax for breakpoints

   The correct syntax to pause execution with Pry is binding.pry.

2. Step 2: Check other options for correctness

   Other options like breakpoint.pry, pry.binding, and debug.pry are invalid method calls.

3. Final Answer:

   binding.pry -> Option D

4. Quick Check:

   Correct Pry breakpoint syntax = D [OK]

Hint: Use exactly 'binding.pry' to pause with Pry [OK]

Common Mistakes:

• Swapping method and object order
• Using non-existent methods
• Forgetting to require 'pry'

3. What will be the output when running this Ruby code with byebug inserted?

def add(a, b)
  byebug
  a + b
end

puts add(2, 3)

medium

A. 5

B. byebug error

C. nil

D. SyntaxError

Solution

1. Step 1: Understand what byebug does

   It pauses execution allowing inspection but does not change the return value.

2. Step 2: Trace the function call and output

   The method add(2, 3) returns 5, which is printed by puts.

3. Final Answer:

   5 -> Option A

4. Quick Check:

   byebug pauses but output is 5 [OK]

Hint: byebug pauses but returns normal output [OK]

Common Mistakes:

• Expecting byebug to change output
• Thinking byebug causes errors
• Confusing pause with program stop

4. You inserted binding.pry in your Ruby code, but when you run it, the program does not pause. What is the most likely reason?

medium

A. You used byebug instead of binding.pry

B. You forgot to require the 'pry' gem in your code

C. The Ruby version does not support debugging

D. You placed binding.pry after the return statement

Solution

1. Step 1: Check if 'pry' gem is loaded

   Without require 'pry', binding.pry is undefined and won't pause.

2. Step 2: Verify placement and usage

   Using binding.pry correctly requires the gem loaded; placing after return stops execution before breakpoint.

3. Final Answer:

   You forgot to require the 'pry' gem in your code -> Option B

4. Quick Check:

   Missing require 'pry' stops pause [OK]

Hint: Always require 'pry' before using binding.pry [OK]

Common Mistakes:

• Not requiring the gem
• Placing breakpoint after return
• Confusing pry with byebug usage

5. You want to debug a method that processes a list of numbers and stops only when a number is negative. Which debugging tool and approach is best to use?

hard

A. Use puts statements to print all numbers

B. Insert byebug at the start of the method without any condition

C. Insert binding.pry inside the loop with a condition to pause only if the number is negative

D. Run the program without breakpoints and guess the error

Solution

1. Step 1: Understand conditional breakpoints

   Using binding.pry with a condition lets you pause only when needed, saving time.

2. Step 2: Compare other options

   Using byebug without condition pauses every time, puts is less interactive, guessing is ineffective.

3. Final Answer:

   Insert binding.pry inside the loop with a condition to pause only if the number is negative -> Option C

4. Quick Check:

   Conditional breakpoint with binding.pry = A [OK]

Hint: Use conditional binding.pry to pause only on negative numbers [OK]

Common Mistakes:

• Pausing unconditionally causing many stops
• Relying only on print statements
• Ignoring debugging tools