When I'm in the debugger (from a browser statement for ex.), if I find the code that gives an error, R exits the debugger. But I want to stay in it. How can I do that automatically (e.g. I don't want to manually have to remember to reset option(error) to something when I'm in the debugger.
You can use options(error = recover). This will exit the debugging session and immediately offer to enter a new one, with variables as they were at the time of the error.
For example,
options(error = recover)
myfun <- function(x) x + "a" ; debug(myfun) ; myfun(2)
This leads to the following interactive lines:
debugging in: myfun(2)
debug: x + "a"
Browse[2]> n
Error in x + "a" (from #1) : non-numeric argument to binary operator
Enter a frame number, or 0 to exit
1: myfun(2)
Selection: 1
Browse[3]> ls()
[1] "x"
Browse[3]> print(x)
[1] 2
Browse[3]>
To make this happen automatically, just put the options(error=recover) call as a default for the session.
Your problem may be due to a misunderstanding about the levels of debug. If, for example, you execute debug(myfunc); myfunc(...) , and myfunc calls some other function, then the called function is not in debug mode. If that function throws an error, R quite properly exits the entire environment. Imagine if it didn't: what would happen during non-debug mode?
One solution is: after entering myfunc in debug mode, and you know what called function throws the error, to execute debug(that_func) so you can follow its error path.
Another workaround is to manually enter the offending function call at the debug prompt (instead of hitting RETURN to have the debugger run the next line of your code). In this way, you'll get the error message back but since it was user-called rather than actually executing a line of the code being debug-run, the debugger will not exit.
Please feel free to comment if this is unclear.
Related
I frequently need to debug a function in one of my R packages, and find it convenient to add test code and print statements throughout the code. Then the function is a method inside a package, running tests from the console will use the package-stored old version of the function and not the new test version. I often resort to something like cat *.r > /tmp/package.r and then source('/tmp/package.r') to override all functions, which allows the test function to be prioritized. But this doesn't work when I have .Fortran or similar calls within the package.
Is there an elegant way to debug with function overrides within the correct version of a local package?
Regardless of your IDE, you can reload your package under development with devtools:
devtools::load_all("path/to/your/package/directory")
This should load it to your R session (RStudio has buttons and keyboard shortcuts for this too)
This is an extension of my comment above. As said in the comment checkout this guide for more detail.
To inspect calls dynamically during calls, editing functions and adding code can be done using the trace(func, edit = TRUE) method. However it is not the recommended methodology for doing so in any programming language. It is however recommended to instead perform debugging. Luckily debugging in R is simpler than many other languages. Some of the most noticeable methods for debugging in R is obtained using
debug(func) or debugonce(func)
trace
browser
I'll ignore trace's main usage, and only pass over it briefly in conjunction with browser.
Take this small example code
x <- 3
f <- function(x){
x <- x ** 2
x
}
Now if we wanted to "go into" this function and inspect what happens we can use the debug method simply by doing
debug(f) # alt: debugonce(f)
f(x)
and the following shows in the console
debugging in: f(x)
debug at #1: {
x <- x^2
x
}
We see 2 things: The original call in line 1, the function debugged including a function-line-number (#1) with the body in the function (potentially truncated). In addition the command has changed to Browse[n] (where n is a number), indicating we are in the debugger.
At this point nothing has run so in the "environment" tab in Rstudio we can see x | x. Note that x is still a promise (its value is delayed until used or changed). If we execute x we get the value [1] 3 and we see the environment change to x | 3 (it has been forced, and is no longer a promise).
Inside the debugger we can use the following commands to "walk through" the function
n to move to the "next line"
s to move to the "next line", or if the current call is a function, "step" into the function (debug this function)
f to move forward until the next break (with the added utility that if you are in a loop you stop at "loop end".
c to move until next break point or end of function (without breaking at end of loops).
Q to exit immediately
It you click n for example you will see
debug at #2: x <- x^2
printed in the console. This indicates the line that is executed next. Notice the value of x in the environment and run n again, notice the value changed from x | 3 to x | 9 and
debug at #3: x
is printed. This being the last line pressing n again will exit the function and print
exiting from: f(x)
[1] 9
Once you're done debugging you can run undebug(f) to remove the breakpoint and stop the debugger from activating.
This is a simple function, easy to debug, but the idea for more complex functions are the same. If you are in a long loop you can use f to skip to the end of the loop, similar to pressing n a bunch of times. Note that if you hit an error at any point it will exit automatically when the error occurs and you'll have to walk back to the point again or alternatively use browser.
In the case where you have a function like
f2 <- function(x){
x <- x + 2
f(x)
}
you can further step into the nested function call f(x) by using the s command while the line is printing
debug at #3: f(x)
or by using debug(f2) and debug(f) in conjunction. Both will give the same result (try it out!).
Now in many cases you might hit a bug or debug many lines (potentially thousands). In this case, you might have some "idea" where you want to start, and this might not be the start of the function. In this case you can use browser(). This basically sets a breakpoint. Whenever browser() is hit, it will stop and start the debugger (similar to debug(f) and calling f(x) but at a specific point). Try for example
f3 <- function(x){
x1 <- f(x)
browser()
x2 <- f2(x)
c(x1, x2)
}
f3(x)
and you'll notice see
Called from: f3(x)
printed (if you have run undebug(f2) and undebug(f) first).
Lets say it is not your function but a function within a namespace, well then we can even add the breakpoint ourself at run-time. Try for example calling
trace(f3, edit = TRUE)
and you will see an editing window pop up. Simply add browser() at the desired spot and click save. This edits the function within the namespace. It will be reverted once R is closed or alternatively you can remove it with another call to trace(f3, edit = TRUE).
This is interesting. I'm on CentOS 6.9, R-3.4.2. I have a code, tmp.R:
main<-function(){
a = 9
print(a) xyz
print("Should never get here")
}
When I run this, Rscript tmp.R, I get
Error: unexpected symbol in:
" a = 9
print(a) xyz"
No traceback available
[1] "Should never get here"
Error: unexpected '}' in "}"
No traceback available
This is pretty confusing because I never actually called main(). In fact, if I remove the syntax error
(3rd line becomes print(a)), and I run it, there isn't any output. This is the expected behavior in my mind.
QUESTION : Why does R execute code in a script when a syntax error occurs, even when the code isn't explicitly called(!)?
EDIT : It turns out that this behavior seems to be due to having options(error=traceback) being set in my .Rprofile. This is undesirable behavior none the less. It would still be desirable to be able to get tracebacks when in interactive mode and not do this strange code execution in non-interactive mode.
I have an expression that spits out multiple errors:
stop("first")
stop("second")
stop("third")
print("success")
Is there a way to make this expression run all the way to the end (and, if possible, store all of the errors)?
The problem with tryCatch is that it stops execution on the first handled condition (so this will print "There was an error" exactly once).
tryCatch({
stop("first")
stop("second")
stop("third")
print("success")
}, error = function(e) print("There was an error"))
I read that withCallingHandlers will capture conditions and continue execution, so I tried something like this...
withCallingHandlers(
{...},
error = function(e) print("There was an error")
)
...but, although this does print the message, it also fails after the first error, which, as far as I can tell, is because the default restart just runs the current line again.
I think what I need to do is write a custom restart that simply skips the current expression and jumps to the next one, but I'm at a bit of a loss about how to go about that.
(Background: Basically, I'm trying to replicate what happens inside testthat::test_that, which is that even though each failing expectation throws an error, all expectations are run before quitting).
I wonder what the differences between stopifnot() and assertError() are:
assertError() is not found by default (You'll have to load the "tools" package first), but stopifnot() is.
More significantly, assertError() always throws an error message, even if I pass arguments like TRUE or FALSE, while stopifnot() does the obvious and expected thing.
Reading the manual page did not help. What is the correct use instead of assertError(length(x) != 7)? If x is undefined, the statement produces no error, but as soon as it is defined, it is producing errors, independent of the length of x (7 or not).
The main difference is where they should be used.
stopIfnot aim at stopping an execution if some conditions are not met during the run where assertError aim at testing your code.
assertError expect it's parameter to raise an error, this is what happens when x is not defined, there's an error
> length(x) != 7
Error: object 'x' not found
When you pass this expression to assertError, it raise an error and assertError return the conditions met (the error in itself). This allow you to test the failure cases of your code.
So assertError is mostly used in tests cases in a Test Driven Development pattern (TDD), when your code/function is supposed to raise an error for some specific parameters and ensure when you update your function later you're not breaking it.
Example usage of stopifnot and assertError:
mydiv <- function(a,b) {
stopifnot(b>0)
a/b
}
And now lets make a test to ensure this will raise an error if we pass "b" as 0:
tryCatch(
assertError(mydiv(3,0)),
error = function(e) { print("Warning, mydiv accept to divide by 0") }
)
Running this code produce no output, desired behavior.
Now if we comment the stopifnot in mydiv like this:
mydiv <- function(a,b) {
#stopifnot(abs(b)>0)
a/b
}
And testing again the tryCatch block, we get this output:
[1] "Warning, mydiv accept to divide by 0"
This is a small example of testing a function really throw an error as expected.
The tryCatch block is just to showcase with a different message, I hope this give more light on the subject.
Sometimes R throws me errors such as
Error in if (ncol(x) != 2) { : argument is of length zero
with no additional information, when I've written no such code. Is there a general way for finding which function in which package causes an error?
Since most packages come compressed, it isn't trivial to grep /usr/lib/R/library.
You can use traceback() to locate where the last error occurred. Usually it will point you to a call you make in your function. Then I typically put browser() at that point, run the function again and see what is going wrong.
For example, here are two functions:
f2 <- function(x)
{
if (x==1) "foo"
}
f <- function(x)
{
f2(x)
}
Note that f2() assumes an argument of length 1. We can misuse f:
> f(NULL)
Error in if (x == 1) "foo" : argument is of length zero
Now we can use traceback() to locate what went wrong:
> traceback()
2: f2(x) at #3
1: f(NULL)
The number means how deep we are in the nested functions. So we see that f calls f2 and that gives an error at line 3. Pretty clear. We could reassign f with browser placed just before the f2 call now to check it's input. browser() simply allows you to stop executing a function and look around in its environment. Similar to debug and debugonce except that you don't have to execute every line up until the point you know something goes wrong.
Just to add to what #SachaEpskamp has already suggested, setting options(error=recover) and options(show.error.locations=TRUE) can be extremely helpful when debugging unfamiliar code. The first causes R to launch a debugging session on error, giving you the option to invoke the browser at any point in the call stack up to that error. The second option will tell R to include the source line number in the error.