How to get R script line numbers at error?

Question

If I am running a long R script from the command line (R --slave script.R), then how can I get it to give line numbers at errors?

I don't want to add debug commands to the script if at all possible; I just want R to behave like most other scripting languages.

Any updates? Four 4 years later, seems the problem still persists, despite all the mainstream adoption of R. — Gui Ambros, Sep 15 '13 at 00:41
I also have a very long R script with lots of small output, I want to print (underscore)(underscore)LINE/FILE(underscore)(underscore) (line numbers and scriptname) like that in C, instead of hardcoding line-numbers into source. — mosh, Nov 18 '16 at 16:05
I don't know if R internally really has a notion of 'line numbers'. However, it does have a notion of complete tasks, i.e. top level tasks. One could, for example, easily define a task handler to tell one which top-level task failed. Of course, that is no great comfort for those with large chains or big conditional statements. — russellpierce, Jun 22 '17 at 12:50

score 54 · Accepted Answer · edited May 23 '17 at 11:47

This won't give you the line number, but it will tell you where the failure happens in the call stack which is very helpful:

traceback()

[Edit:] When running a script from the command line you will have to skip one or two calls, see traceback() for interactive and non-interactive R sessions

I'm not aware of another way to do this without the usual debugging suspects:

debug()
browser()
options(error=recover) [followed by options(error = NULL) to revert it]

You might want to look at this related post.

[Edit:] Sorry...just saw that you're running this from the command line. In that case I would suggest working with the options(error) functionality. Here's a simple example:

options(error = quote({dump.frames(to.file=TRUE); q()}))

You can create as elaborate a script as you want on an error condition, so you should just decide what information you need for debugging.

Otherwise, if there are specific areas you're concerned about (e.g. connecting to a database), then wrap them in a tryCatch() function.

The solution linked in the first [Edit:] block works for me. The best approach seems to be the comment of @dshepherd, i.e., add `options(error=function() { traceback(2); if(!interactive()) quit("no", status = 1, runLast = FALSE) })` (see comment of accepted answer). I think it would make sense to add it to the answer here rather than only providing a link to another thread. — cryo111, Jul 12 '18 at 11:16
a new option that let's you get the line numbers in the traceback https://github.com/aryoda/tryCatchLog — lunguini, Sep 17 '18 at 17:56

score 15 · Answer 2 · edited Mar 28 '17 at 23:11

15

Doing options(error=traceback) provides a little more information about the content of the lines leading up to the error. It causes a traceback to appear if there is an error, and for some errors it has the line number, prefixed by #. But it's hit or miss, many errors won't get line numbers.

edited Mar 28 '17 at 23:11

Eric Leschinski

146,994
96
417
335

answered Oct 23 '12 at 03:09

Hugh Perkins

7,975
7
63
71

3

Doesn't quite work for me. I've only got one file, and it doesn't show the line number, just says `No traceback available` after the error. – Mark Lakata Mar 24 '16 at 23:42
this doesn't change anything in R 4.0.2 – con Dec 05 '22 at 15:53

score 12 · Answer 3 · edited Mar 27 '19 at 20:33

12

Support for this will be forthcoming in R 2.10 and later. Duncan Murdoch just posted to r-devel on Sep 10 2009 about findLineNum and setBreapoint:

I've just added a couple of functions to R-devel to help with debugging. findLineNum() finds which line of which function corresponds to a particular line of source code; setBreakpoint() takes the output of findLineNum, and calls trace() to set a breakpoint there.

These rely on having source reference debug information in the code. This is the default for code read by source(), but not for packages. To get the source references in package code, set the environment variable R_KEEP_PKG_SOURCE=yes, or within R, set options(keep.source.pkgs=TRUE), then install the package from source code. Read ?findLineNum for details on how to tell it to search within packages, rather than limiting the search to the global environment.

For example,
x <- " f <- function(a, b) {
             if (a > b)  {
                 a
             } else {
                 b
             }
         }"


eval(parse(text=x))  # Normally you'd use source() to read a file...

findLineNum("<text>#3")   # <text> is a dummy filename used by
parse(text=)
This will print
 f step 2,3,2 in <environment: R_GlobalEnv>
and you can use
setBreakpoint("<text>#3")
to set a breakpoint there.

There are still some limitations (and probably bugs) in the code; I'll be fixing thos

edited Mar 27 '19 at 20:33

hirse

2,394
1
22
24

answered Sep 18 '09 at 18:17

Dirk Eddelbuettel

360,940
56
644
725

Thanks. Just signed up for the r-devel mailing list too. I've been avoiding r-help on the assumption that it would clog my inbox (r-sig-finance already does that). – Shane Sep 19 '09 at 16:01
1

don't really understand how this works from the command line without poking around in the R script – Herman Toothrot May 25 '16 at 21:21
1

@hirse: This is an almost ten your old answer. Why on earth did you reformat it to pretend I was quoting? I wasn't, and your change does _not_ reflect my intent. – Dirk Eddelbuettel Mar 27 '19 at 20:49
"Duncan Murdoch just posted:" sounds very much like a quote, but if that is not correct, please revert the edit. I wanted to make it more readable for myself and didn't check the date until I was done. If the whole answer is too outdated, you can also delete it to remove confusion to future readers. – hirse Mar 27 '19 at 20:52
Can you please revert it? Thank you. – Dirk Eddelbuettel Mar 27 '19 at 20:56

score 8 · Answer 4 · answered Oct 11 '16 at 09:52

8

You do it by setting

options(show.error.locations = TRUE)

I just wonder why this setting is not a default in R? It should be, as it is in every other language.

answered Oct 11 '16 at 09:52

Tomas

57,621
49
238
373

1

For background information about this option see https://stat.ethz.ch/R-manual/R-devel/library/base/html/options.html – R Yoda Oct 12 '16 at 10:52
4

This used to work, but was disabled because it isn't reliable. I think it's an attempt to force you into using the RStudio which will eventually be non-free. – Eric Leschinski Mar 28 '17 at 06:48
8

I doubt it. R core and RStudio are very different organizations, and R core in particular are staunch open-sourcers. – Ben Bolker Mar 28 '17 at 15:40
Worked on CentOS 6.9, R-3.4.2 – irritable_phd_syndrome Oct 23 '18 at 11:30
Maybe it's worth mentioning, you should set the options up front, before sourcing any code. – JAponte Jan 29 '19 at 20:58
@JAponte why do you think so? Normally, you can set options at any place in your code. – Tomas Jan 30 '19 at 16:13
For me, it didn't work the other way around. I think the interpreter needs to know how to interpret the source before hand. – JAponte Jan 30 '19 at 16:17
2

this doesn't work in R 4.0.2 – con Dec 05 '22 at 15:54
4

I'm finding the same issue as @con on 4.1.2. Honestly if R can't get a simple feature like this it probably shouldn't be a language in mass circulation – Matt Feb 09 '23 at 15:34

score 3 · Answer 5 · answered Sep 10 '17 at 05:01

Specifying the global R option for handling non-catastrophic errors worked for me, along with a customized workflow for retaining info about the error and examining this info after the failure. I am currently running R version 3.4.1. Below, I've included a description of the workflow that worked for me, as well as some code I used to set the global error handling option in R.

As I have it configured, the error handling also creates an RData file containing all objects in working memory at the time of the error. This dump can be read back into R using load() and then the various environments as they existed at the time of the error can be inspected interactively using debugger(errorDump).

I will note that I was able to get line numbers in the traceback() output from any custom functions within the stack, but only if I used the keep.source=TRUE option when calling source() for any custom functions used in my script. Without this option, setting the global error handling option as below sent the full output of the traceback() to an error log named error.log, but line numbers were not available.

Here's the general steps I took in my workflow and how I was able to access the memory dump and error log after a non-interactive R failure.

I put the following at the top of the main script I was calling from the command line. This sets the global error handling option for the R session. My main script was called myMainScript.R. The various lines in the code have comments after them describing what they do. Basically, with this option, when R encounters an error that triggers stop(), it will create an RData (*.rda) dump file of working memory across all active environments in the directory ~/myUsername/directoryForDump and will also write an error log named error.log with some useful information to the same directory. You can modify this snippet to add other handling on error (e.g., add a timestamp to the dump file and error log filenames, etc.).

options(error = quote({
  setwd('~/myUsername/directoryForDump'); # Set working directory where you want the dump to go, since dump.frames() doesn't seem to accept absolute file paths.
  dump.frames("errorDump", to.file=TRUE, include.GlobalEnv=TRUE); # First dump to file; this dump is not accessible by the R session.
  sink(file="error.log"); # Specify sink file to redirect all output.
  dump.frames(); # Dump again to be able to retrieve error message and write to error log; this dump is accessible by the R session since not dumped to file.
  cat(attr(last.dump,"error.message")); # Print error message to file, along with simplified stack trace.
  cat('\nTraceback:');
  cat('\n');
  traceback(2); # Print full traceback of function calls with all parameters. The 2 passed to traceback omits the outermost two function calls.
  sink();
  q()}))

Make sure that from the main script and any subsequent function calls, anytime a function is sourced, the option keep.source=TRUE is used. That is, to source a function, you would use source('~/path/to/myFunction.R', keep.source=TRUE). This is required for the traceback() output to contain line numbers. It looks like you may also be able to set this option globally using options( keep.source=TRUE ), but I have not tested this to see if it works. If you don't need line numbers, you can omit this option.
From the terminal (outside R), call the main script in batch mode using Rscript myMainScript.R. This starts a new non-interactive R session and runs the script myMainScript.R. The code snippet given in step 1 that has been placed at the top of myMainScript.R sets the error handling option for the non-interactive R session.
Encounter an error somewhere within the execution of myMainScript.R. This may be in the main script itself, or nested several functions deep. When the error is encountered, handling will be performed as specified in step 1, and the R session will terminate.
An RData dump file named errorDump.rda and and error log named error.log are created in the directory specified by '~/myUsername/directoryForDump' in the global error handling option setting.

At your leisure, inspect error.log to review information about the error, including the error message itself and the full stack trace leading to the error. Here's an example of the log that's generated on error; note the numbers after the # character are the line numbers of the error at various points in the call stack:

Error in callNonExistFunc() : could not find function "callNonExistFunc"
Calls: test_multi_commodity_flow_cmd -> getExtendedConfigDF -> extendConfigDF

Traceback:
3: extendConfigDF(info_df, data_dir = user_dir, dlevel = dlevel) at test_multi_commodity_flow.R#304
2: getExtendedConfigDF(config_file_path, out_dir, dlevel) at test_multi_commodity_flow.R#352
1: test_multi_commodity_flow_cmd(config_file_path = config_file_path, 
spot_file_path = spot_file_path, forward_file_path = forward_file_path, 
data_dir = "../", user_dir = "Output", sim_type = "spot", 
sim_scheme = "shape", sim_gran = "hourly", sim_adjust = "raw", 
nsim = 5, start_date = "2017-07-01", end_date = "2017-12-31", 
compute_averages = opt$compute_averages, compute_shapes = opt$compute_shapes, 
overwrite = opt$overwrite, nmonths = opt$nmonths, forward_regime = opt$fregime, 
ltfv_ratio = opt$ltfv_ratio, method = opt$method, dlevel = 0)

At your leisure, you may load errorDump.rda into an interactive R session using load('~/path/to/errorDump.rda'). Once loaded, call debugger(errorDump) to browse all R objects in memory in any of the active environments. See the R help on debugger() for more info.

This workflow is enormously helpful when running R in some type of production environment where you have non-interactive R sessions being initiated at the command line and you want information retained about unexpected errors. The ability to dump memory to a file you can use to inspect working memory at the time of the error, along with having the line numbers of the error in the call stack, facilitate speedy post-mortem debugging of what caused the error.

Somehow this no longer works. `error.log` no longer includes line number or filename information in R 4.0 (I haven’t tried other versions). — Konrad Rudolph, Jun 01 '21 at 12:27

score -1 · Answer 6 · answered Jan 09 '19 at 11:09

-1

First, options(show.error.locations = TRUE) and then traceback(). The error line number will be displayed after #

answered Jan 09 '19 at 11:09

den2042

497
4
4

How to get R script line numbers at error?

6 Answers6

Linked

Related