I've posted a patch to bugs.r-project.org that fixes the traceback() issue. It's not specific to findFun3; you get the same problem with errors from expressions like 1 + "a" In my testing, I occasionally saw cases where show.error.locations = TRUE didn't work. I'll try to track down a reproducible case, and perhaps a patch to fix it. Duncan Murdoch On 2025-01-20 9:37 a.m., Duncan Murdoch wrote:> Sorry, I'm not seeing the first problem now: > options(show.error.locations = TRUE) works fine. Not sure what I did > wrong before. > > I'm still seeing `traceback()` failing to report the attempt to call > nofunction(). I suppose this is because a context is never set up for > the failed call. Perhaps findFun3 could set up a fake context so that > traceback() adds one more entry? > > Duncan Murdoch > > > On 2025-01-19 3:39 p.m., Duncan Murdoch wrote: >> Thanks for pointing out the options. Using >> >> options(show.error.locations = TRUE) >> >> works on Ivo's example, but it doesn't show a location if the error >> happens in a function that doesn't have srcrefs, because the known >> location isn't on the top of the stack. >> >> Perhaps TRUE (and maybe "top"?) should look back through the stack until >> it finds a known location, and report that, or another option (e.g. >> "highest"?) could be added to do that. >> >> And still I think traceback() should show the top call in Ivo's example. >> >> Duncan >> >> >> On 2025-01-19 11:46 a.m., luke-tierney at uiowa.edu wrote: >>> 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 to the >>>> development team and a very high benefit to newbies. >>> >>> No. There are already many ways to influence the way the default error >>> handler prints information about errors, mstly via options(). In >>> particular you may want to look at entries in ?options for >>> >>> show.error.locations >>> showErrorCalls >>> showWarningCalls >>> >>> and adjust your options settings accordingly. >>> >>> Best, >>> >>> luke >>> >>>> >>>> Regards, >>>> >>>> /ivo >>>> >>>> On Sun, Jan 19, 2025 at 2:39?AM Duncan Murdoch <murdoch.duncan at gmail.com> wrote: >>>>> >>>>> On 2025-01-18 8:27 p.m., Ivo Welch wrote: >>>>>> I am afraid my errors are worse! (so are my postings. I should have >>>>>> given an example.) >>>>>> >>>>>> ``` >>>>>> x <- 1 >>>>>> y <- 2 >>>>>> nofunction("something stupid I am doing!") >>>>>> z <- 4 >>>>>> ``` >>>>>> >>>>>> and >>>>>> >>>>>> ``` >>>>>>> source("where-is-my-water.R") >>>>>> Error in nofunction("something stupid I am doing!") : >>>>>> could not find function "nofunction" >>>>>> ``` >>>>>> >>>>>> and no traceback is available. >>>>> >>>>> Okay, I see. In that case traceback() doesn't report the line, but it >>>>> still is known internally. You can see it using the following function: >>>>> >>>>> showKnownLocations <- function() { >>>>> calls <- sys.calls() >>>>> srcrefs <- sapply(calls, function(v) if (!is.null(srcref <- attr(v, >>>>> >>>>> "srcref"))) { >>>>> srcfile <- attr(srcref, "srcfile") >>>>> paste0(basename(srcfile$filename), "#", srcref[1L]) >>>>> } else ".") >>>>> cat("Current call stack locations:\n") >>>>> cat(srcrefs, sep = " ") >>>>> cat("\n") >>>>> } >>>>> >>>>> I haven't done much testing on this, but I think it can be called >>>>> explicitly from any location if you want to know how you got there, or >>>>> you can set it as the error handler using >>>>> >>>>> options(error = showKnownLocations) >>>>> >>>>> For example, try this script: >>>>> >>>>> options(error = showKnownLocations) >>>>> f <- function() showKnownLocations() >>>>> x <- 1 >>>>> f() >>>>> y <- 2 >>>>> nofunction("something stupid I am doing!") >>>>> z <- 4 >>>>> >>>>> I see this output from source("test.R"): >>>>> >>>>> > source("test.R") >>>>> Current call stack locations: >>>>> . . . . test.R#4 test.R#2 >>>>> Error in nofunction("something stupid I am doing!") : >>>>> could not find function "nofunction" >>>>> Current call stack locations: >>>>> . . . . test.R#6 >>>>> >>>>> The first report is from the explicit call in f() on line 2 that was >>>>> invoked on line 4, and the second report happens during error handling. >>>>> >>>>> I supppose the fact that traceback() isn't showing you the line 6 >>>>> location could be considered a bug. >>>>> >>>>> Duncan Murdoch >>>>> >>>>> >>>> >>>> ______________________________________________ >>>> 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. >>>> >>> >> >
There is a little catch-22 here. I would be happy to fund a student to spend a summer cleaning up the error messages and making it more userfriendly, but the catch-22 problem is that I don?t have much confidence that this effort would be adopted into the basic R distribution ? and the only way I think this will be worth it is if it rolls into the standard distribution. (Well, with an option( verbose.errors ) enabling it.). with confidence of adoption, I think few are willing to exert the effort. I would contribute a few thousand dollars to the cause if it funded the R core team hiring such a summer programming assistant for this purpose, too, if they don?t trust a random student I would hire. But again?only if the expectation is that this will flow into the distribution. If you think I am misreading the situation, please let me know who I should ask. Regards, /ivo> On Jan 20, 2025, at 2:56?PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > > I've posted a patch to bugs.r-project.org that fixes the traceback() issue. It's not specific to findFun3; you get the same problem with errors from expressions like > > 1 + "a" > > In my testing, I occasionally saw cases where show.error.locations = TRUE didn't work. I'll try to track down a reproducible case, and perhaps a patch to fix it. > > Duncan Murdoch > > > > On 2025-01-20 9:37 a.m., Duncan Murdoch wrote: >> Sorry, I'm not seeing the first problem now: >> options(show.error.locations = TRUE) works fine. Not sure what I did >> wrong before. >> I'm still seeing `traceback()` failing to report the attempt to call >> nofunction(). I suppose this is because a context is never set up for >> the failed call. Perhaps findFun3 could set up a fake context so that >> traceback() adds one more entry? >> Duncan Murdoch >> On 2025-01-19 3:39 p.m., Duncan Murdoch wrote: >>> Thanks for pointing out the options. Using >>> >>> options(show.error.locations = TRUE) >>> >>> works on Ivo's example, but it doesn't show a location if the error >>> happens in a function that doesn't have srcrefs, because the known >>> location isn't on the top of the stack. >>> >>> Perhaps TRUE (and maybe "top"?) should look back through the stack until >>> it finds a known location, and report that, or another option (e.g. >>> "highest"?) could be added to do that. >>> >>> And still I think traceback() should show the top call in Ivo's example. >>> >>> Duncan >>> >>> >>> On 2025-01-19 11:46 a.m., luke-tierney at uiowa.edu wrote: >>>> 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 to the >>>>> development team and a very high benefit to newbies. >>>> >>>> No. There are already many ways to influence the way the default error >>>> handler prints information about errors, mstly via options(). In >>>> particular you may want to look at entries in ?options for >>>> >>>> show.error.locations >>>> showErrorCalls >>>> showWarningCalls >>>> >>>> and adjust your options settings accordingly. >>>> >>>> Best, >>>> >>>> luke >>>> >>>>> >>>>> Regards, >>>>> >>>>> /ivo >>>>> >>>>> On Sun, Jan 19, 2025 at 2:39?AM Duncan Murdoch <murdoch.duncan at gmail.com> wrote: >>>>>> >>>>>> On 2025-01-18 8:27 p.m., Ivo Welch wrote: >>>>>>> I am afraid my errors are worse! (so are my postings. I should have >>>>>>> given an example.) >>>>>>> >>>>>>> ``` >>>>>>> x <- 1 >>>>>>> y <- 2 >>>>>>> nofunction("something stupid I am doing!") >>>>>>> z <- 4 >>>>>>> ``` >>>>>>> >>>>>>> and >>>>>>> >>>>>>> ``` >>>>>>>> source("where-is-my-water.R") >>>>>>> Error in nofunction("something stupid I am doing!") : >>>>>>> could not find function "nofunction" >>>>>>> ``` >>>>>>> >>>>>>> and no traceback is available. >>>>>> >>>>>> Okay, I see. In that case traceback() doesn't report the line, but it >>>>>> still is known internally. You can see it using the following function: >>>>>> >>>>>> showKnownLocations <- function() { >>>>>> calls <- sys.calls() >>>>>> srcrefs <- sapply(calls, function(v) if (!is.null(srcref <- attr(v, >>>>>> >>>>>> "srcref"))) { >>>>>> srcfile <- attr(srcref, "srcfile") >>>>>> paste0(basename(srcfile$filename), "#", srcref[1L]) >>>>>> } else ".") >>>>>> cat("Current call stack locations:\n") >>>>>> cat(srcrefs, sep = " ") >>>>>> cat("\n") >>>>>> } >>>>>> >>>>>> I haven't done much testing on this, but I think it can be called >>>>>> explicitly from any location if you want to know how you got there, or >>>>>> you can set it as the error handler using >>>>>> >>>>>> options(error = showKnownLocations) >>>>>> >>>>>> For example, try this script: >>>>>> >>>>>> options(error = showKnownLocations) >>>>>> f <- function() showKnownLocations() >>>>>> x <- 1 >>>>>> f() >>>>>> y <- 2 >>>>>> nofunction("something stupid I am doing!") >>>>>> z <- 4 >>>>>> >>>>>> I see this output from source("test.R"): >>>>>> >>>>>> > source("test.R") >>>>>> Current call stack locations: >>>>>> . . . . test.R#4 test.R#2 >>>>>> Error in nofunction("something stupid I am doing!") : >>>>>> could not find function "nofunction" >>>>>> Current call stack locations: >>>>>> . . . . test.R#6 >>>>>> >>>>>> The first report is from the explicit call in f() on line 2 that was >>>>>> invoked on line 4, and the second report happens during error handling. >>>>>> >>>>>> I supppose the fact that traceback() isn't showing you the line 6 >>>>>> location could be considered a bug. >>>>>> >>>>>> Duncan Murdoch >>>>>> >>>>>> >>>>> >>>>> ______________________________________________ >>>>> 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. >>>>> >>>> >>> >
And now I've found the elusive bug in show.error.locations = TRUE as well, and posted a patch for that too. Back to the original topic of this thread: I think most users should routinely use options(show.error.locations = TRUE) e.g. in their .Rprofile. That will often speed up bug fixes, especially if my patch is incorporated. Duncan Murdoch On 2025-01-20 5:56 p.m., Duncan Murdoch wrote:> I've posted a patch to bugs.r-project.org that fixes the traceback() > issue. It's not specific to findFun3; you get the same problem with > errors from expressions like > > 1 + "a" > > In my testing, I occasionally saw cases where show.error.locations > TRUE didn't work. I'll try to track down a reproducible case, and > perhaps a patch to fix it. > > Duncan Murdoch > > > > On 2025-01-20 9:37 a.m., Duncan Murdoch wrote: >> Sorry, I'm not seeing the first problem now: >> options(show.error.locations = TRUE) works fine. Not sure what I did >> wrong before. >> >> I'm still seeing `traceback()` failing to report the attempt to call >> nofunction(). I suppose this is because a context is never set up for >> the failed call. Perhaps findFun3 could set up a fake context so that >> traceback() adds one more entry? >> >> Duncan Murdoch >> >> >> On 2025-01-19 3:39 p.m., Duncan Murdoch wrote: >>> Thanks for pointing out the options. Using >>> >>> options(show.error.locations = TRUE) >>> >>> works on Ivo's example, but it doesn't show a location if the error >>> happens in a function that doesn't have srcrefs, because the known >>> location isn't on the top of the stack. >>> >>> Perhaps TRUE (and maybe "top"?) should look back through the stack until >>> it finds a known location, and report that, or another option (e.g. >>> "highest"?) could be added to do that. >>> >>> And still I think traceback() should show the top call in Ivo's example. >>> >>> Duncan >>> >>> >>> On 2025-01-19 11:46 a.m., luke-tierney at uiowa.edu wrote: >>>> 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 to the >>>>> development team and a very high benefit to newbies. >>>> >>>> No. There are already many ways to influence the way the default error >>>> handler prints information about errors, mstly via options(). In >>>> particular you may want to look at entries in ?options for >>>> >>>> show.error.locations >>>> showErrorCalls >>>> showWarningCalls >>>> >>>> and adjust your options settings accordingly. >>>> >>>> Best, >>>> >>>> luke >>>> >>>>> >>>>> Regards, >>>>> >>>>> /ivo >>>>> >>>>> On Sun, Jan 19, 2025 at 2:39?AM Duncan Murdoch <murdoch.duncan at gmail.com> wrote: >>>>>> >>>>>> On 2025-01-18 8:27 p.m., Ivo Welch wrote: >>>>>>> I am afraid my errors are worse! (so are my postings. I should have >>>>>>> given an example.) >>>>>>> >>>>>>> ``` >>>>>>> x <- 1 >>>>>>> y <- 2 >>>>>>> nofunction("something stupid I am doing!") >>>>>>> z <- 4 >>>>>>> ``` >>>>>>> >>>>>>> and >>>>>>> >>>>>>> ``` >>>>>>>> source("where-is-my-water.R") >>>>>>> Error in nofunction("something stupid I am doing!") : >>>>>>> could not find function "nofunction" >>>>>>> ``` >>>>>>> >>>>>>> and no traceback is available. >>>>>> >>>>>> Okay, I see. In that case traceback() doesn't report the line, but it >>>>>> still is known internally. You can see it using the following function: >>>>>> >>>>>> showKnownLocations <- function() { >>>>>> calls <- sys.calls() >>>>>> srcrefs <- sapply(calls, function(v) if (!is.null(srcref <- attr(v, >>>>>> >>>>>> "srcref"))) { >>>>>> srcfile <- attr(srcref, "srcfile") >>>>>> paste0(basename(srcfile$filename), "#", srcref[1L]) >>>>>> } else ".") >>>>>> cat("Current call stack locations:\n") >>>>>> cat(srcrefs, sep = " ") >>>>>> cat("\n") >>>>>> } >>>>>> >>>>>> I haven't done much testing on this, but I think it can be called >>>>>> explicitly from any location if you want to know how you got there, or >>>>>> you can set it as the error handler using >>>>>> >>>>>> options(error = showKnownLocations) >>>>>> >>>>>> For example, try this script: >>>>>> >>>>>> options(error = showKnownLocations) >>>>>> f <- function() showKnownLocations() >>>>>> x <- 1 >>>>>> f() >>>>>> y <- 2 >>>>>> nofunction("something stupid I am doing!") >>>>>> z <- 4 >>>>>> >>>>>> I see this output from source("test.R"): >>>>>> >>>>>> > source("test.R") >>>>>> Current call stack locations: >>>>>> . . . . test.R#4 test.R#2 >>>>>> Error in nofunction("something stupid I am doing!") : >>>>>> could not find function "nofunction" >>>>>> Current call stack locations: >>>>>> . . . . test.R#6 >>>>>> >>>>>> The first report is from the explicit call in f() on line 2 that was >>>>>> invoked on line 4, and the second report happens during error handling. >>>>>> >>>>>> I supppose the fact that traceback() isn't showing you the line 6 >>>>>> location could be considered a bug. >>>>>> >>>>>> Duncan Murdoch >>>>>> >>>>>> >>>>> >>>>> ______________________________________________ >>>>> 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. >>>>> >>>> >>> >> >