I often find myself hunting where in my program an error has happened, (of course, in R, many error messages are mysterious in themselves, too, making it even harder.) the way I do it is mostly with inserting `message()` statements. what I would really like to have is a parser that inserted 'curline <<- ##' into the R code, where '##' is the filename and line number. something like 'addtracker one.R two.R' and thereafter I can run two.R and, when the program dies, use `print curline` to find out where my error has roughly occurred. has someone already written such an 'instrumenter'?
Hi Ivo,
I maintain 'package:this.path' that I believe does what you want. I
regularly add this to my own code when I need to:
warning(sprintf("remove this later at %s#%d",
this.path::try.this.path(), this.path::LINENO()), call. = FALSE,
immediate. = TRUE)
Of course, modify as needed.
Regards,
Iris
On Sat, Jan 18, 2025 at 6:41?PM Ivo Welch <ivo.welch at gmail.com>
wrote:>
> I often find myself hunting where in my program an error has happened,
> (of course, in R, many error messages are mysterious in themselves,
> too, making it even harder.) the way I do it is mostly with inserting
> `message()` statements.
>
> what I would really like to have is a parser that inserted 'curline
> <<- ##' into the R code, where '##' is the filename and
line number.
> something like 'addtracker one.R two.R' and thereafter I can run
two.R
> and, when the program dies, use `print curline` to find out where my
> error has roughly occurred.
>
> has someone already written such an 'instrumenter'?
>
> ______________________________________________
> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
https://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
I recommend making sure your code is built with functions and using the debugger and breakpoints (e.g. [1]) to follow the flow of the code to lead you to where your problem is. If you are used to building thousand-line top-level scripts then you might not welcome this suggestion, but in that you already have problems you have not admitted to... such things (large top-level scripts) are monsters that will swallow you whole at the slightest change in R, packages, or data. [1] https://rstudio-education.github.io/hopr/debug.html On January 18, 2025 3:41:18 PM PST, Ivo Welch <ivo.welch at gmail.com> wrote:>I often find myself hunting where in my program an error has happened, >(of course, in R, many error messages are mysterious in themselves, >too, making it even harder.) the way I do it is mostly with inserting >`message()` statements. > >what I would really like to have is a parser that inserted 'curline ><<- ##' into the R code, where '##' is the filename and line number. >something like 'addtracker one.R two.R' and thereafter I can run two.R >and, when the program dies, use `print curline` to find out where my >error has roughly occurred. > >has someone already written such an 'instrumenter'? > >______________________________________________ >R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see >https://stat.ethz.ch/mailman/listinfo/r-help >PLEASE do read the posting guide https://www.R-project.org/posting-guide.html >and provide commented, minimal, self-contained, reproducible code.-- Sent from my phone. Please excuse my brevity.
On 2025-01-18 6:41 p.m., Ivo Welch wrote:> I often find myself hunting where in my program an error has happened, > (of course, in R, many error messages are mysterious in themselves, > too, making it even harder.) the way I do it is mostly with inserting > `message()` statements. > > what I would really like to have is a parser that inserted 'curline > <<- ##' into the R code, where '##' is the filename and line number. > something like 'addtracker one.R two.R' and thereafter I can run two.R > and, when the program dies, use `print curline` to find out where my > error has roughly occurred. > > has someone already written such an 'instrumenter'?The basic R parser already does that. For example, try putting these lines in test.R: x <- 1 y <- 2 stop("something bad!") z <- 4 Then run source("test.R"), and it will die with the uninformative message Error in eval(ei, envir) : something bad! But then traceback() will show you the line: > traceback() 5: stop("something bad!") at test.R#3 4: eval(ei, envir) 3: eval(ei, envir) 2: withVisible(eval(ei, envir)) 1: source("~/temp/test.R") See the first line of the traceback? It shows that the problem was on line 3 of test.R. If that line was in a function that had been called from somewhere else, both the function line triggering the error and the line that called the function would have been shown in different parts of the traceback. This all depends on calling source() with parameter keep.source = TRUE. The default value of that parameter is getOption("keep.source"), so if you're not seeing the line numbers, you may have set that option to FALSE. Duncan Murdoch
On 2025/01/19 01:41, Ivo Welch wrote:> I often find myself hunting where in my program an error has happened, > (of course, in R, many error messages are mysterious in themselves, > too, making it even harder.) the way I do it is mostly with inserting > `message()` statements.tried something like RStudio? el