debug() lets you step through a function line by line.
traceback() shows the call stack after an error happens.
Examples
This will start debugging my_function. You can step through each line when you run it.
R Programming
debug(my_function)
my_function(5)
After an error, this shows where the error happened in the call stack.
R Programming
traceback()
This pauses the program at that point and lets you inspect variables.
R Programming
browser()
# Put this inside your function where you want to pause execution
When an error happens, you can pick a frame to debug interactively.
R Programming
options(error = recover)
# This lets you choose where to debug after an error occurs
Sample Program
This program pauses inside my_function so you can check the value of y before continuing.
R Programming
my_function <- function(x) {
y <- x + 1
browser() # Pause here to check values
z <- y * 2return(z)
}
my_function(3)
OutputSuccess
Important Notes
Use debug() to step through functions without changing code.
browser() is useful to pause exactly where you want inside your code.
After fixing bugs, use undebug() to stop debugging a function.
Summary
Debugging tools help find and fix errors by letting you see what your code does step-by-step.
Use debug(), browser(), and traceback() to understand problems.
These tools make coding easier and help you learn how your program works.
Practice
(1/5)
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
Step 1: Understand the purpose of debug()
The debug() function lets you step through a function line-by-line to see what happens inside.
Step 2: Compare with other functions
traceback() shows the call stack after an error, browser() pauses execution but debug() is designed for stepping through.
Final Answer:
debug() -> Option B
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
Step 1: Recall correct debug() syntax
The debug() function is called with the function name as an argument: debug(myFunc).
Step 2: Identify invalid syntax
Options A, B, and D use invalid R syntax for function calls or operators.
Final Answer:
debug(myFunc) -> Option D
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
Step 1: Understand debug() usage
debug() is used with a function name outside the function, not inside it.
Step 2: Analyze code behavior
Calling debug() inside a function without arguments causes an error because debug expects a function name.
Final Answer:
Throws an error because debug() needs a function name -> Option C
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
Step 1: Identify purpose of traceback()
traceback() shows the call stack, listing functions called before the error.
Step 2: Differentiate from other tools
debug() and browser() help step through code, stop() halts execution but does not show call history.
Final Answer:
traceback() -> Option A
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
Step 1: Understand browser() usage
Inserting browser() pauses execution at that line and lets you inspect variables interactively.
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.
Step 3: Recognize stop() role
stop() halts execution with an error but does not allow interactive inspection.
Final Answer:
Use browser() inside calcStats at desired lines -> Option A
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
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.