I sometimes load multiple packages that export functions of the same name. For example, both Hmisc and dplyr have a summarize function, and I sometimes load both packages. I then call summarize, thinking that I am calling dplyr::summarize when I am really calling Hmisc::summarize. When that happens, I get an error message like this:
Error in summarize(., mean = mean(instRating)) :
argument "by" is missing, with no default
The message is initially hard to understand, because my code contains no errors. It takes me a minute to realize that I've called a function in the wrong package. The error message would be easier to understand if its first line included the name of the relevant package:
Error in Hmisc::summarize(., mean = mean(instRating)) :
Is there a way to force R to display the package name in these error messages?
I know that I can get around the problem by typing out dplyr::summarize or by changing the order in which I load packages. But my interest lies with adding detail to R's error messages.
From the documentation of the base option error:
'error': either a function or an expression governing the handling
of non-catastrophic errors such as those generated by 'stop'
as well as by signals and internally detected errors. If the
option is a function, a call to that function, with no
arguments, is generated as the expression. By default the
option is not set: see 'stop' for the behaviour in that case.
The functions 'dump.frames' and 'recover' provide
alternatives that allow post-mortem debugging. Note that
these need to specified as e.g. 'options(error =
utils::recover)' in startup files such as '.Rprofile'.
So it should be possible to define a function that returns the name of the package where the function that’s throwing the error lives. For example:
library(dplyr)
library(Hmisc)
data(mtcars)
print_package <- function() {
calls <- sys.calls()
call <- calls[[length(calls) - 1]]
fun.name <- as.character(call)[1]
pkg.name <- sub("package:", "", getAnywhere(fun.name)$where[1], fixed = TRUE)
message (paste0("In ", pkg.name))
}
options(error = print_package)
summarize(mtcars$mpg)
Returns:
Error in summarize(mtcars$mpg) :
argument "by" is missing, with no default
In Hmisc
Edit (using rlang::trace_back)
It turns out that there is a much cleaner way of doing this (credit goes to Hadley Wickham and his "Advanced R, Second edition"):
library(dplyr)
library(Hmisc)
data(mtcars)
print_trace_back <- function() {
print(rlang::trace_back(bottom = sys.frame(-1)))
}
options(error = print_trace_back)
Seems to handle errors gracefully:
> summarize(mtcars$mpg)
Error in summarize(mtcars$mpg) :
argument "by" is missing, with no default
█
1. └─Hmisc::summarize(mtcars$mpg)
>
> Hmisc::summarize(mtcars$mpg)
Error in Hmisc::summarize(mtcars$mpg) :
argument "by" is missing, with no default
█
1. └─Hmisc::summarize(mtcars$mpg)
>
> summarize(mtcars$mpg, as.character(mtcars$apa), mean)
Error in tapply(X, INDEX, FUN, ..., simplify = simplify) :
arguments must have same length
█
1. └─Hmisc::summarize(mtcars$mpg, as.character(mtcars$apa), mean)
2. └─Hmisc::mApply(X, byc, FUN, ..., keepmatrix = nc > 1)
3. └─base::tapply(X, INDEX, FUN, ..., simplify = simplify)
4. └─base::stop("arguments must have same length")
>
> (function() stop("Error"))()
Error in (function() stop("Error"))() : Error
█
1. └─(function() stop("Error"))()
2. └─base::stop("Error")
You can try conflict_prefer("summarize", "dplyr") from conflicted package by Hadley Wickham. One drawback is that you need to identify winner for every conflict.
Related
Using the syuzhet package in R, the following works but returns a warning message:
object <- get_text_as_string("path/name.txt")
When I put this in a function, it returns the same warning error but does NOT change the value of object:
gen <- function(file){
object <- get_text_as_string(file)
}
gen("path/name.txt")
This is the warning message, if it matters:
Warning message:
In readLines(path_to_file) :
incomplete final line found on 'path/name.txt'
...but again, I get that from get_text_as_string() when used outside of the function, but it DOES change the value of object.
Anyone have any advice? There must be something I don't understand about functions?
(I've looked for similar questions/answers, if I've missed the right one I'd be happy to just be directed there.)
I'm trying to substitute lapply function with mclapply on a shiny application, with the trace function.
I'm trying to narrow the trace to the used package's namespace, but it is not working.
Most errors are problems of inputs in lapply, either by embedded function in lapply or more than one function as input.
EXAMPLE of Output:
Loading required package: shiny
Tracing function "lapply" in package "base"
Tracing lapply(paths, function(p) { .... on entry
Error in lapply(X, FUN, ...) : argument "FUN" is missing, with no default
Tracing lapply(keys, get, missing) on entry
Error in lapply(X, FUN, ...) : argument "FUN" is missing, with no default
Tracing lapply(x, f) on entry
Tracing lapply(x, f) on entry
Here is how I'm calling trace function:
trace(base::lapply, tracer=substitute(parallel::mclapply(match.call())),where=namespace.vec)
and namespace.vec variable has the used packages namespaces used in the application.
Thank you very much in advance.
I'm working on functions which catches input variables and preprocess them before evaluation.
I would like to ignore RStudio warning (yellow triangle) with tooltip message missing argument to function call.
Below code is detected by RStudio as warning which in my use case is not a warning.
f = function(a, b) match.call()
f(a = list("a","b",,"d",,,"g",), b = list(,,"c"))
Missing argument is valid use case.
Can I somehow set to ignore this type of warning?
You can use options to turn all warnings off. The argument is showWarnCalls and is a boolean. Use as such:
options(showWarnCalls = FALSE)
Please note this is dangerous as this turns off all of your warnings. Perhaps you could turn warnings off before running the function that commits them and then turn them back on afterward. Example:
options(showWarnCalls = FALSE)
### Your Code ###
options(showWarnCalls = TRUE)
I am running a script that loops over a list of stock pair combinations... occasionally the script stops running due to an error generated by differing data lengths between pair combo and I simply remove the mismatched stock from consideration):
Error in model.frame.default(formula = stckY ~ stckX + 0, drop.unused.levels = TRUE) :
variable lengths differ (found for 'stckX')
Is there any way I can make R / Rstudio play a sound when the error message occurs so that I can be alerted without having to keep my eyes on the screen while the script is looping along?
I can generate sounds linearly using:
beep <- function(n = 3){
for(i in seq(n)){
system("rundll32 user32.dll,MessageBeep -1")
Sys.sleep(.5)
}
}
beep()
but how can I do this conditional on an error message?
Building on #frankc answer and #hrbrmstr comment, a way to do this:
install.packages("beepr")
library(beepr)
options(error = beep)
try options(error = beep)
you would still need to define beep before you do this. Haven't verified this works but it should per ?options:
'error': either a function or an expression governing the handling
of non-catastrophic errors such as those generated by 'stop'
as well as by signals and internally detected errors. If the
option is a function, a call to that function, with no
arguments, is generated as the expression. The default value
is 'NULL': see 'stop' for the behaviour in that case. The
functions 'dump.frames' and 'recover' provide alternatives
that allow post-mortem debugging. Note that these need to
specified as e.g. 'options(error = utils::recover)' in
startup files such as '.Rprofile'.
I'm facing a strange issue in R.
Consider the following code (a really simplified version of the real code but still having the problem) :
library(timeSeries)
tryCatch(
{
specificWeekDay <- 2
currTs <- timeSeries(c(1,2),c('2012-01-01','2012-01-02'),
format='%Y-%m-%d',units='A')
# just 2 dates out of range
start <- time(currTs)[2]+100*24*3600
end <- time(currTs)[2]+110*24*3600
# this line returns an empty timeSeries
currTs <- window(currTs,start=start,end=end)
message("Up to now, everything is OK")
# this is the line with the uncatchable error
currTs[!(as.POSIXlt(time(currTs))$wday %in% specificWeekDay),] <- NA
message("I'm after the bugged line !")
},error=function(e){message(e)})
message("End")
When I run that code in RGui, I correctly get the following output:
Up to now, everything is OK
error in evaluating the argument 'i' in
selecting a method for function '[<-': Error in
as.POSIXlt.numeric(time(currTs)) : 'origin' must be supplied
End
Instead, when I run it through RScript (in windows) using the following line:
RScript.exe --vanilla "myscript.R"
I get this output:
Up to now, everything is OK
Execution interrupted
It seems like RScript crashes...
Any idea about the reason?
Is this a timeSeries package bug, or I'm doing something wrong ?
If the latter, what's the right way to be sure to catch all the errors ?
Thanks in advance.
EDIT :
Here's a smaller example reproducing the issue that doesn't use timeSeries package. To test it, just run it as described above:
library(methods)
# define a generic function
setGeneric("foo",
function(x, ...){standardGeneric("foo")})
# set a method for the generic function
setMethod("foo", signature("character"),
function(x) {x})
tryCatch(
{
foo("abc")
foo(notExisting)
},error=function(e)print(e))
It seems something related to generic method dispatching; when an argument of a method causes an error, the dispatcher cannot find the signature of the method and conseguently raises an exception that tryCatch function seems unable to handle when run through RScript.
Strangely, it doesn't happen for example with print(notExisting); in that case the exception is correctly handled.
Any idea about the reason and how to catch this kind of errors ?
Note:
I'm using R-2.14.2 on Windows 7
The issue is in the way the internal C code implementing S4 method dispatch tries to catch and handle some errors and how the non-interactive case is treated in this approach. A work-around should be in place in R-devel and R-patched soon.
Work-around now committed to R-devel and R-patched.
Information about tryCatch() [that the OP already knew and used but I didn't notice]
I think you are missing that your tryCatch() is not doing anything special with the error, hence you are raising an error in the normal fashion. In interactive use the error is thrown and handled in the usual fashion, but an error inside a script run in a non-interactive session (a la Rscript) will abort the running script.
tryCatch() is a complex function that allows the potential to trap and handle all sorts of events in R, not just errors. However by default it is set up to mimic the standard R error handling procedure; basically allow the error to be thrown and reported by R. If you want R to do anything other than the basic behaviour then you need to add a specific handler for the error:
> e <- simpleError("test error")
> tryCatch(foo, error = function(e) e,
+ finally = writeLines("There was a problem!"))
There was a problem!
<simpleError in doTryCatch(return(expr), name, parentenv, handler): object 'foo'
not found>
I suggest you read ?tryCatch in more detail to understand better what it does.
An alternative is to use try(). To modify your script I would just do:
# this is the line with the uncatchable error
tried <- try(currTs[!(as.POSIXlt(time(currTs))$wday %in% specificWeekDay),] <- NA,
silent = TRUE)
if(inherits(tried, "try-error")) {
writeLines("There was an error!")
} else {
writeLines("Everything worked fine!")
}
The key bit is to save the object returned from try() so you can test the class, and to have try() operate silently. Consider the difference:
> bar <- try(foo)
Error in try(foo) : object 'foo' not found
> bar <- try(foo, silent = TRUE)
> class(bar)
[1] "try-error"
Note that in the first call above, the error is caught and reported as a message. In the second, it is not reported. In both cases an object of class "try-error" is returned.
Internally, try() is written as a single call to tryCatch() which sets up a custom function for the error handler which reports the error as a message and sets up the returned object. You might wish to study the R code for try() as another example of using tryCatch().