32

I observed a different between an interactive and non-interaction R session about traceback() which I do not understand. For the code below, it will produce an error, but in an interactive R session, I can see the traceback information, whereas if I save the code to test.R and call it via Rscript test.R or R -f test.R, I can no longer see the traceback:

f = function() {
  on.exit(traceback())
  1 + 'a'
}
f()

In an interactive R session:

> f = function() {
+   on.exit(traceback())
+   1 + 'a'
+ }
> f()
Error in 1 + "a" : non-numeric argument to binary operator
1: f()

Non-interactive execution:

$ Rscript test.R 
Error in 1 + "a" : non-numeric argument to binary operator
Calls: f
No traceback available 
Execution halted

I did not see an explanation in ?traceback, and I'm wondering if there is a way to enable traceback for non-interactive R sessions. Thanks!

4

4 回答 4

32

With default values of its arguments, traceback() will look for an object named .Traceback in the baseenv() for information on the call stack. It looks (from src/main/errors.c) like .Traceback is only created if, among other conditions, R_Interactive || haveHandler, suggesting that this object is not created during non-interactive sessions. If there is no object named .Traceback, you will get the message "No traceback available".

However, by passing a non-NULL value to the x argument of traceback(), one can obtain information about the call stack from a non-interactive session. With a non-zero integer value (indicating the number of calls to skip in the stack), c-level functions (R_GetTraceback) are called to investigate the call stack instead of looking in .Traceback.

So there are a couple ways to obtain traceback information in a non-interactive session:

f = function() {
  on.exit(traceback(1))
  1 + 'a'
}
f()

Or, setting options as Brandon Bertelsen suggested

options(error=function()traceback(2))

The different values passed to x in the two examples account for the different number of functions to skip

  1. In the on.exit example, traceback(1) skips the call to traceback().

  2. In the example setting options, there is an extra anonymous function that calls traceback() which should/could also be skipped.

In the example in the OP, there's not much more information gained by using traceback() compared to the automatic traceback provided in the case of an error in a non-interactive session. However, with functions that take (and are passed) arguments, using traceback() will be much more informative than the standard presentation of the call stack in the non-interactive session.

于 2012-10-29T09:58:37.857 回答
3

There is also the possibility to dump debugging information and load them later on. (See good ?debugger help pages and comments on the topic)

via e.g.:

options(error = quote(dump.frames("testdump", TRUE)))

...

load("testdump.rda")
debugger(testdump)

or 

options(error = quote({dump.frames(to.file = TRUE); q(status = 1)}))
于 2016-09-21T07:04:35.877 回答
1

BenBarnes's answer and dshepherd's comment are life saving. I will add one more parameter to avoid clogging up the screen in case one of the parameters is very big.

options(error=function(){traceback(2,max.lines=3);if(!interactive())quit("no",status=1,runLast=FALSE)})
于 2020-10-14T12:20:31.933 回答
0

The problem with options(error=function()traceback(2)) is that it does not stop the script execution, which is really really dangerous.

To avoid that you can use:

options(error = function() { 
  traceback(2); 
  options(error = NULL); 
  stop("exiting after script error") 
})

which will properly print the stack trace, then exit properly.

于 2021-09-17T08:28:56.697 回答