6.195
Using the Debugger in R Studio

Introduction

This lesson provides an introduction to the interactive debugger in R Studio that can be used to step through R Scripts (but not R Notebooks). It has many of the features of a typical debugger such as setting breakpoints and stepping through code and into and out of functions.

Before We Start

The reader of this lesson might find the short video tutorial below helpful in getting an overview of the debugger in the R Studio IDE for R. Consider watching them before proceeding with the lesson. Also, be sure to follow along in R Studio.

The video below provides a more in-depth debugging example in which functions are debugged.

Debugging

The process of debugging – or finding logic errors in programs – is a complex subject and often more art than science. You will find that you become better over time. This lesson focuses on the interactive debugger and not as much on general debugging principles. See the references for more information on that topic.

Debugging means experimentation, hypothesis testing, elimination, trial-and-error, and lots of patience.

Finding your bug is a process of confirming the many things that you believe are true — until you find one which is not true.

—Norm Matloff

From an abstract perspective, debugging means finding where the code does not work as expected. It runs but it does not produce the result you expect. This can be from an error in your programming logic, a misinterpretation of a language construct, or a defect in a package function or even the language itself. Naturally, the former two are most common and we will focus on those in this lesson.

To find why your code isn’t behaving as you expect, you generally follow the approach below within a debugger – although a debugger isn’t strictly necessary but very convenient. Once you are used to an interactive debugger, not having one will definitely be felt.

1. Run your code
2. Stop the code at the line where you suspect an issue
3. Inspect the code for mistakes, inspect the contents of objects, look at the value of variables
4. proceed running the code statement by statement and repeat step (3) after each step

It is often simpler to extract code that isn’t running into a separate “sandbox” – a new R Script that just contains the flawed code. That way you can experiment without messing up your actual production code.

Setting Breakpoints

To enter the debugger you need to enter debug mode. A common way is to set a breakpoint at a line and then run your code. It will automatically stop at the breakpoint. To set a breakpoint at a line in RStudio¹, click to the left of the line number in the editor, or pressing Shift+F9 when your cursor is on the desired line. If that all fails, then go to the line where you want your code to stop and select menu item Debug/Toggle Breakpoint. A red dot will appear next to the line where you have a breakpoint. To remove the breakpoint, just do the same steps again – it is a toggle.

Now, if you run the code it will stop at that line and then you can go to the Console and print out variable values and run ad hoc statements to experiment. To run your R code like a program (starting at the first statement), you need to “source” the file. In R Studio that means you select the “Source” button.

Once you are in debug mode and you have stopped at your first breakpoint, you can step through the code line by line. Now, you need to apply your detective skills and your experience – and not just experience programming in R, but also all of your programming experience with other languages. Many of the same issues occur in all languages. For example, if you get an error when trying to load a file (like a CSV with read.csv) then you should always suspect that the file cannot be found. If you didn’t specify an absolute and full path to the file, then you need to assume that R uses a different default folder than where you believe you are. Once you enter the debugger, call getwd() to find out where R is looking for file. The short video below illustrates this common problem in R².

To exit debug mode, you select Debug/Stop Debugging, press SHIFT-F8, or hit the Stop button within the debugging controls as shown below. Stopping means to quit the current program and stop any further statements from executing.

Of course, you can also use the controls to continue to the next breakpoint, press “Continue”, or step into a block, loop, or function, or execute the remainder of a loop or function. Experiment with each control to see what it does.

Rather than setting breakpoints in the editor, you can also include a call to the function browser() in your code which, when encountered, will pause execution and place you in the debugger – it functions as a programmatically set breakpoint and can be invoked conditionally.

The code below illustrates this. On line there is a call on line 6 to the function browser().

df < read.csv(file = fn)

n <- nrow(df)

if (n < 1)
  browser()

for (i in 1:n)
{
  # ...
}

Summary

Debugging, the process of removing logic errors, is an important part of programming. An interactive debugger, coupled with language-independent forensic strategies, is a valuable tool in the arsenal of the professional programmer. This lessons provided an overview of the key features of the interactive debugger built into the R Studio IDE.

---

Files & Resources

All Files for Lesson 6.195

---

See Also

• 6.191 Debugging R Code

References

Wickham, H. (n.d.) Advanced R. Chapter 22: Debugging

Debugging R Code: What they Forgot to Teach About R

McPherson, J. (2021). Debugging with the RStudio IDE. Dec 28, 2021.

Errata

None collected yet. Let us know.

---

1. Setting breakpoints and using the debugger is only possible with R Scripts and cannot be used with R Markdown documents. To debug R Markdown code chunks you would need to copy them to an R Script, debug them, and then copy back to the code chunks.↩︎

2. There is even a package to help with finding out where you are, the here package. It can help make code “location independent”.↩︎