Debugging R (browser, traceback)

Debugging is the disciplined process of finding and fixing errors in your code, and R gives you a toolkit — traceback, browser, debug, and tryCatch — to inspect the call stack, pause execution mid-run, and recover gracefully from failures.

Learn Debugging R (browser, traceback) in our free R course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick…

Part of the free R course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

By the end of this lesson you'll read a traceback, set breakpoints with browser(), step through a function with debug(), and protect code from crashing with tryCatch().

What You'll Learn in This Lesson

1️⃣ Reading the Call Stack with traceback()

When an error fires, the first question is "where did it actually break?" traceback() prints the chain of calls that led to the error. Read it bottom-up: the bottom is your original call, the top is the function that failed.

2️⃣ Pausing and Stepping: browser() and debug()

To watch your code run, drop browser() on a line and it pauses there, opening a Browse> prompt where you inspect variables and step with n (next) and c (continue). To step through an entire function without editing it, use debug() or, more often, debugonce() .

3️⃣ Recovering Gracefully with tryCatch()

Sometimes you don't want an error to stop everything. tryCatch() wraps risky code with handlers for error and warning , plus a finally block that always runs — so a single bad input becomes an NA and a log message instead of a crash.

Your turn. Use the debugger to find the bug, then apply the fix and run it.

Combine the tools: use tryCatch() to survive junk input, message() to report problems, and the recover option to investigate interactively.

📋 Quick Reference — Debugging

Practice quiz

What does traceback() show after an error?

  • The value of every variable
  • A fixed version of your code
  • The call stack of functions that led to the error
  • The runtime in seconds

Answer: The call stack of functions that led to the error. traceback() prints the chain of calls active when the error occurred.

How should you read a traceback?

  • Bottom-up: bottom is the original call, top is where it failed
  • Top-down: top is the original call
  • Left to right
  • Only the middle line matters

Answer: Bottom-up: bottom is the original call, top is where it failed. The bottom is your call; the top is the function that actually failed.

What does browser() do when execution reaches it?

  • Opens a web browser
  • Prints all variables and continues
  • Restarts the function
  • Pauses and opens an interactive prompt to inspect state

Answer: Pauses and opens an interactive prompt to inspect state. browser() halts at that line and lets you inspect variables live.

At the Browse> prompt, what does typing n do?

  • Quits the debugger
  • Runs the next line
  • Names a variable
  • Negates a value

Answer: Runs the next line. n steps to the next line; c continues, Q quits.

How does debugonce(f) differ from debug(f)?

  • It enters the debugger only on the next call, then disarms
  • It debugs every call until undebug()
  • It deletes the function
  • It runs the function twice

Answer: It enters the debugger only on the next call, then disarms. debugonce() is one-shot; debug() persists until undebug(f).

Which call stops debug(f) from triggering on every future call?

  • stopdebug(f)
  • debugoff(f)
  • undebug(f)
  • rm(f)

Answer: undebug(f). undebug(f) removes the persistent debug flag set by debug(f).

What is tryCatch() primarily for?

  • Stepping through code line by line
  • Recovering gracefully from errors and warnings
  • Printing the call stack
  • Setting breakpoints

Answer: Recovering gracefully from errors and warnings. tryCatch() handles conditions so a script can keep running.

In tryCatch(), when does the finally block run?

  • Only on success
  • Only on error
  • Never, it is optional syntax
  • Always, whether or not an error occurred

Answer: Always, whether or not an error occurred. finally always runs after the expression and handlers.

Why call traceback() immediately after an error?

  • It only works once per session
  • A later command overwrites the recorded stack
  • It needs internet access
  • It modifies your variables

Answer: A later command overwrites the recorded stack. traceback() reports the most recent error, so run it before anything else.

What does options(error = recover) enable?

  • Automatic bug fixing
  • Suppression of all errors
  • An interactive post-mortem to pick a frame to inspect
  • Faster execution

Answer: An interactive post-mortem to pick a frame to inspect. On error it lets you choose a stack frame and inspect it; reset with options(error = NULL).