R Studio not breaking in code on error?

[rovyko]

I used R Studio many months ago and had no problems with the debugger, but now it seems that I can't get the IDE to break and show me the environment where an error has occurred. For example, if I have code split over two files in the working directory, along with a folder named realfolder.

tools.r

savedata <- function (data, path){
  stopifnot(class(data) == "data.frame")
  write.csv(data, path)
}

analysis.r

source("tools.r")

a = c(1,2,3)
b = c(10,20,30)
d = data.frame(a,b)

savedata(d, './realfolder/d.csv') # call A
savedata(1, './realfolder/d.csv') # call B
savedata(d, './fakefolder/d.csv') # call C

When I set Debug -> On Error to Break in Code, and then run tools.r, an error occurs on the line with call B, and the stop is triggered by stopifnot(class(data) == "data.frame") as expected. However, the IDE does not pause on that line, but only shows the error message:

Error in savedata(1, "./realfolder/d.csv") : 
  class(data) == "data.frame" is not TRUE

Calling traceback() gives all the relevant info, but I remember it was possible to get a snapshot at the time of the error to see what variables in the environment were causing the issue.

When I set Debug -> On Error to Error Inspector I get an interactive traceback, but no break. If I comment out the line with call B, an error will occur in packaged function from call C since fakefolder does not exist. In this case, even the error inspector shows only an error message.

Is this normal behavior? Is it possible to get the effect of browser() at each point in the traceback when an error has occurred?

[kevinushey]

A few things that aren't clear to me:

1. How exactly are you running the code? E.g. are you highlighting the code and clicking the Run button, or something else?

2. Is the R debugger activating at all (ie: do you see Browse[1]> in the prompt)?

3. If the debugger is activating, is the issue here that it is not placing you in the correct context?

[rovyko]

Sorry I made a mistake in the original post, so let me clarify. When I press the Source button in the upper right corner of the editor while editing the analysis.r file, I get the following in the Console:

> source('C:/temp/debug/rdebugging/analysis.r')
Error in savedata(1, "./realfolder/d.csv") : 
  class(data) == "data.frame" is not TRUE

This happens even though I set Debug -> On Error to Error Inspector. It doesn't enter the debugger.

An answer on StackOverflow suggested that I add the line options(error = utils::recover) to the beginning. When I source analysis.r with that line at the beginning, I am given a traceback in the console an which frame I want to browse to. It seems that options(error = browser) gives a similar result, but with fewer frames.

So it appears that the Debug -> On Error selection is not working? I am using RStudio Desktop 1.2.5033 on Windows 10

[kevinushey]

Thanks for the feedback. My understanding is that the RStudio debugger normally only operates when running code line-by-line; not when run through source().

[nirgrahamuk]

Hi.
If you want to be dropped into the browser() style debugger. then

1. set the debug menu option for Rstudio to be on error - break in code.
2. wrap your code in a function, and run that.

testme <- function()
  {
  source("tools.r")

a = c(1,2,3)
b = c(10,20,30)
d = data.frame(a,b)

savedata(d, './d.csv') # call A
savedata(1, './d.csv') # call B
savedata(d, './d.csv') # call C
}

testme()

this takes me to a browser() like environment at the critical juncture...

[rovyko]

Using Code -> Run All gave the same result.

[rovyko]

So my ideal solution to the problem would be to run the following line in the console:

options(error=browser)

Which causes the debugger to browse to the scope of an error when it is encountered as I would have expected.

I am going to accept nirgrahamuk's post as the solution because I think it's a general good practice to wrap the procedural part of your script in a function.

I still think the Traceback browser could be more helpful by actually browsing to the error location in functions that you have written, but that is another issue.