Debugging tools in R Programming - Step-by-Step Execution

Concept Flow - Debugging tools

Start Program

↓

Run Code

↓

Error Occurs?

No→Program Ends

Yes↓

Use Debugging Tools

↓

Inspect Variables & Flow

↓

Fix Error

↓

Run Code Again

↩Back to Error Occurs?

The program runs and if an error happens, debugging tools help inspect and fix it before running again.

Execution Sample

R Programming

x <- 5
y <- "a"
result <- x + y
print(result)

This code tries to add a number and a letter, causing an error to demonstrate debugging.

Execution Table

Step	Code Line	Action	Result/Output	Error
1	x <- 5	Assign 5 to x	x = 5	None
2	y <- "a"	Assign 'a' to y	y = 'a'	None
3	result <- x + y	Try to add x and y	None	Error: non-numeric argument to binary operator
4	print(result)	Not executed due to error	None	Skipped

💡 Execution stops at step 3 due to type error when adding number and string.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3
x	undefined	5	5	5
y	undefined	undefined	"a"	"a"
result	undefined	undefined	undefined	error (not assigned)

Key Moments - 3 Insights

Why does the program stop at step 3 and not print the result?

Because adding a number and a string causes an error at step 3, the program stops and does not reach the print statement (see execution_table step 3 and 4).

How can I check the values of variables before the error?

Use debugging tools like print() or debug() to see variable values before the error line, as shown by the variable_tracker after steps 1 and 2.

What does the error 'non-numeric argument to binary operator' mean?

It means you tried to do math (+) with a value that is not a number, like a letter string, causing the error at step 3.

Visual Quiz - 3 Questions

Look at the execution_table, what is the error message at step 3?

A Error: non-numeric argument to binary operator

B Error: object 'result' not found

C Error: unexpected symbol

D No error

💡 Hint

Check the 'Error' column in execution_table row for step 3.

According to variable_tracker, what is the value of y after step 2?

A 5

B "a"

C undefined

D error

💡 Hint

Look at the 'y' row and 'After Step 2' column in variable_tracker.

If y was assigned 3 instead of "a", what would happen at step 3?

A Program would stop before step 3

B Error would still occur

C result would be 8

D print(result) would be skipped

💡 Hint

Think about adding two numbers instead of number and string, check execution_table step 3.

Concept Snapshot

Debugging tools help find and fix errors.
Run code, watch for errors.
Use print() or debug() to check variables.
Fix errors and rerun.
Common error: type mismatch (number + string).
Repeat until no errors.

Full Transcript

This example shows running R code that assigns 5 to x and 'a' to y, then tries to add them. The addition causes an error because you cannot add a number and a string. The program stops before printing the result. Debugging tools like print statements or the debug function help check variable values before the error. Fixing the error (for example, making y a number) allows the program to run fully. The execution table traces each step, showing where the error happens. The variable tracker shows how variables change. Understanding the error message helps fix the problem. This process repeats until the code runs without errors.

Practice

1. Which R function allows you to step through a function line-by-line to find errors?

easy

A. traceback()

B. debug()

C. browser()

D. stop()

Solution

1. Step 1: Understand the purpose of debug()

   The debug() function lets you step through a function line-by-line to see what happens inside.

2. Step 2: Compare with other functions

   traceback() shows the call stack after an error, browser() pauses execution but debug() is designed for stepping through.

3. Final Answer:

   debug() -> Option B

4. Quick Check:

   Step through function = debug() [OK]

Hint: Use debug() to step through function code line-by-line [OK]

Common Mistakes:

• Confusing traceback() with stepping through code
• Thinking browser() automatically steps through all lines
• Using stop() which just halts execution

2. Which of the following is the correct way to start debugging a function named myFunc in R?

easy

A. debug myFunc()

B. debug:myFunc()

C. debug->myFunc()

D. debug(myFunc)

Solution

1. Step 1: Recall correct debug() syntax

   The debug() function is called with the function name as an argument: debug(myFunc).

2. Step 2: Identify invalid syntax

   Options A, B, and D use invalid R syntax for function calls or operators.

3. Final Answer:

   debug(myFunc) -> Option D

4. Quick Check:

   Correct debug syntax = debug(myFunc) [OK]

Hint: Use parentheses with debug() and function name [OK]

Common Mistakes:

• Omitting parentheses after debug
• Using colon or arrow instead of parentheses
• Adding spaces incorrectly in function call

3. What will be the output after running this R code?

f <- function(x) {
  debug()
  y <- x + 1
  return(y)
}
f(3)

medium

A. Starts debugging mode and waits for user input

B. Returns 4 immediately without debugging

C. Throws an error because debug() needs a function name

D. Prints 3 and exits

Solution

1. Step 1: Understand debug() usage

   debug() is used with a function name outside the function, not inside it.

2. Step 2: Analyze code behavior

   Calling debug() inside a function without arguments causes an error because debug expects a function name.

3. Final Answer:

   Throws an error because debug() needs a function name -> Option C

4. Quick Check:

   debug() inside function without name = error [OK]

Hint: debug() needs a function name, not called inside function body [OK]

Common Mistakes:

• Thinking debug() works inside function without arguments
• Expecting immediate return without debugging
• Confusing debug() with browser()

4. You run a function and get an error. Which R command helps you see the sequence of function calls that led to the error?

medium

A. traceback()

B. debug()

C. browser()

D. stop()

Solution

1. Step 1: Identify purpose of traceback()

   traceback() shows the call stack, listing functions called before the error.

2. Step 2: Differentiate from other tools

   debug() and browser() help step through code, stop() halts execution but does not show call history.

3. Final Answer:

   traceback() -> Option A

4. Quick Check:

   Call stack after error = traceback() [OK]

Hint: Use traceback() to see error call sequence [OK]

Common Mistakes:

• Using debug() to see call stack after error
• Confusing browser() with traceback()
• Expecting stop() to show call history

5. You want to debug a complex function calcStats that calls other functions internally. Which approach helps you pause execution at any line inside calcStats and inspect variables interactively?

hard

A. Use browser() inside calcStats at desired lines

B. Use debug(calcStats) only once before calling

C. Use traceback() after running calcStats

D. Use stop() to halt execution at errors

Solution

1. Step 1: Understand browser() usage

   Inserting browser() pauses execution at that line and lets you inspect variables interactively.

2. Step 2: Compare with debug() and traceback()

   debug() steps through entire function but cannot pause at arbitrary lines; traceback() only shows call stack after error.

3. Step 3: Recognize stop() role

   stop() halts execution with an error but does not allow interactive inspection.

4. Final Answer:

   Use browser() inside calcStats at desired lines -> Option A

5. Quick Check:

   Pause anywhere interactively = browser() [OK]

Hint: Insert browser() where you want to pause and inspect [OK]

Common Mistakes:

• Relying only on debug() to pause anywhere
• Using traceback() before error occurs
• Expecting stop() to allow variable inspection