similar to: Re: [R] No traceback available when using try(...) (PR#6669)

Hello, 1. The Situation : ------------------------ The stack traceback is not available when error ouccured in a try(....) -- test.R -------------------------------- f<-function(a){ return ( log(a) ) } try(f("A")) traceback() ------------------------------------------- I get the following message : > try(f("A")) Error in log(x) : Non-numeric argument to mathematical

On Fri, 12 Mar 2004 12:28:48 +0100, Edouard DUCHESNAY <duchesnay@shfj.cea.fr> wrote : >> > 1. The Situation : >> > ------------------------ >> > The stack traceback is not available when error ouccured in a try(....) >> >> It's a bug in 1.8.1. It has been fixed. >> >> -thomas >I have patched R (Version 1.8.1 Patched (2004-03-11))

Hi all, The help for traceback states: Errors which are caught _via_ 'try' or 'tryCatch' do not generate a traceback, so what is printed is the call sequence for the last uncaught error, and not necessarily for the last error. Is there any way to get a traceback (or something similar) for an error raised inside a try block? Regards, Hadley -- http://had.co.nz/

I'm a little confused by a change in behavior from 2.2.1 to 2.3.0. In 2.2.1 I could do > ## Create a list of data frames in 2.2.1 > b <- list(x = data.frame(a = 1, b = 2), y = data.frame(a = 1, b = 2)) > do.call("rbind", b) a b x 1 2 y 1 2 But in 2.3.0 I get > do.call("rbind", b) Error in data.frame(a = c("1", "1"), b =

The following code produces an error in current R-devel f <- function(value) { if(!missing(value)) 100 else 2 } e <- new.env() makeActiveBinding("x", f, e) eval(substitute(list(x)), e) The error, after calling 'eval' is Error in eval(expr, envir, enclos) : element 1 is empty; the part of the args list of 'list'

Luke, thanks for considering the issue.? I would like to try to separate the problem into two parts, as I _think_ your comments address primarily part 2 below: 1. How can we avoid significant and possibly crippling ?? stalls on error with these non-standard calls. 2. What is the best way to view these non-standard calls. I agree that issue 2. requires further thought and discussion under a

We also have a few other suggestions and wishes about backtrace storage and display on the one hand, and display of constructed calls on the other hand. Perhaps it would be better to open a different wishlist item for traceback() to keep the discussions focused? FWIW I think deparsing backtraces lazily is a great idea. Displaying 1 line per call by default in interactive sessions, while being

The tracebacks are compressed into a single line because we're using PyObject_Str, but they are just about usable if not very readable. For example you would see an error like this: nbdkit: error: ./python-exception.py: config_complete: error: ['Traceback (most recent call last):\n', ' File "./python-exception.py", line 54, in config_complete\n raise_error1()\n',

When large calls cause errors R may stall for extended periods.? This is particularly likely to happen with `do.call`, as in this example with a 24 second stall: ??? x <- runif(1e7) ??? system.time(do.call(paste0, list(abs, x)))? # intentional error ??? ## Error in (function (..., collapse = NULL)? : ??? ##?? cannot coerce type 'builtin' to vector of type 'character' ??? ##

On Sun, 19 Jan 2025, Ivo Welch wrote: > Hi Duncan ? Wonderful. Thank you. Bug or no bug, I think it would be > a huge improvement for user-friendliness if R printed the last line by > default *every time* a script dies. Most computer languages do so. > > Should I file it as a request for improvement to the R code > development team? Maybe R can be improved at a very low cost

The 'cacher' package contains a set of routines for caching statistical analyses. The idea is that an analysis stored in a file (say, 'foo.R') is run and the results of the evaluated expressions are cached in a database. These cached results can subsequently be packaged up and distributed over the interweb. I've just uploaded to CRAN version 0.1-2 of the 'cacher'

The 'cacher' package contains a set of routines for caching statistical analyses. The idea is that an analysis stored in a file (say, 'foo.R') is run and the results of the evaluated expressions are cached in a database. These cached results can subsequently be packaged up and distributed over the interweb. I've just uploaded to CRAN version 0.1-2 of the 'cacher'

understood. but, please, consider not people like me but unwary beginners and students of R. I have used R now for decades, and even I am baffled by it. Couldn't you make R code easier to debug not only for people like me (who can indeed tweak their environments) but also for novice users? On Sun, Jan 19, 2025 at 8:46?AM <luke-tierney at uiowa.edu> wrote: > > On Sun, 19 Jan

Funny, it works for me on R-patched > f <- function(a) { return(log(a)) } > f("A") Error in log(x) : Non-numeric argument to mathematical function > traceback() 2: log(a) 1: f("A") > try(f("A")) Error in log(x) : Non-numeric argument to mathematical function > traceback() 2: log(a) 1: f("A") This is on > version _

I would like to have an automatic traceback printed on error. Is there a way to do this? options(error=traceback) seems to print the previous error, not the current error. I'm guessing this is because the traceback is not set until the error handler is done running. > options(error=traceback) > stop("1") Error: 1 No traceback available > stop("2") Error: 2 1:

Dear R experts---I may have asked this in the past, but I don't think I figured out how to do this. I would like to execute traceback() automatically if my R program dies---every R programI ever invoke. I guessed that I could have wrapped my entire R code into tryCatch( ... oodles of R code , error = function(e) traceback(), finally = cat("done") } but the traceback docs tell

Has something changed with traceback's in R-patched? When I running the examples for ?traceback, I get > foo <- function(x) { print(1); bar(2) } > bar <- function(x) { x + a.variable.which.does.not.exist } > foo(2) # gives a strange error [1] 1 Error in bar(2) : Object "a.variable.which.does.not.exist" not found > traceback() No traceback available

I've noticed a change in the way grep() behaves between the 1.9.0 release and a recent R-patched. On 1.9.0 I get the following output: > x <- dget(file = url("http://www.biostat.jhsph.edu/~rpeng/names.R")) > length(grep("^l\\w+tmean", x, perl = TRUE, value = TRUE)) [1] 84 And on R-patched (2004-06-11) I get > x <- dget(file =

Hi! Is there a way to write the information stored in the .Traceback variable to a file? When I try it with dump() ".Traceback" <- list("dump(.Traceback, file = \"Mytraceback.R\")") Or there are other ways to write this information on the disk if an error occurs? Eryk

The addition of `.traceback` in r70207 adds one more function to the call stack when invoking `traceback()`.? This changes the output of one of the examples to include the error handler call: > options(error = function() traceback(2)) > foo(2) [1] 1 Error in bar(2) : object 'a.variable.which.does.not.exist' not found 3: (function () ?? traceback(2))() at #1 2: bar(2) at #1 1: