I am starting to use the futile.logger package. There is a nice FATAL error logging that I would like to use in conjuction with stop.
But say I do :
stop(flog.fatal('crash for some reason'))
I get
[FATAL] [2015-07-06 22:46:54] [base.stop] crash for some reason
Error:
[FATAL] [2015-07-06 22:46:54] [base.stop] crash for some reason
How can I just stop (abort the program), after logging what the flog.fatal logged
So [FATAL] [2015-07-06 22:46:54] [base.stop] crash for some reason and that's it
Your question as stated seems trivial? Just do
flog.fatal('crash for some reason'); stop()
?
(I personally find futile.logger more useful for writing text messages to a file, not to the console, but also print the messages to the console with R's conditions message(), warning(), stop() etc.
The value returned by flog.fatal is a character vector (length 1) which stop prints.
res <- flog.fatal('crash for some reason')
print(res)
As alternative you can use ftry function from the futile.logger package.
> futile.logger::ftry(log("a"))
ERROR [2017-08-22 10:50:51] non-numeric argument to mathematical function
Error in log("a") : non-numeric argument to mathematical function
Related
Is it possible to change the Error label inside the stop() function?
For example:
stop("This is a error!")
Error: This is a error!
change to:
Incorrect: This is a error!
I need to use stop function, not warning or message functions.
There's a risk that this could be confusing for users seeing something that's an stopping the code without explicitly announcing that it's an error.
If you can guarantee that the user is using English, you can hack it a bit using the backspace character (\b) with:
stop("\b\b\b\b\b\b\bIncorrect: This is a error!")
but this relies on knowing how long the word "Error" is in English, a version that also works in other languages would be trickier.
Edited to add that even in English this doesn't work from inside a function:
throw_an_error <- function()stop("\b\b\b\b\b\b\bIncorrect: This is a error!")
throw_an_error()
# Error in throw_an_errIncorrect: This is a error!
There are currently four different error logging levels: "#debug, #info, #warn, and #error" all of which have a different use case and implications of their use. In general, when is it appropriate to use the different logging macros?
From the docs:
#debug "Verbose debugging information. Invisible by default"
#info "An informational message"
#warn "Something was odd. You should pay attention"
#error "A non fatal error occurred"
Read more in the Julia docs here. In particular, it's important to note that #error does NOT throw an error, it merely logs an error and continues execution. If you want to throw an error, use the error function instead.
I am executing following code in R using "IF" and the condition executed (I was expecting, it will give error message),
if("TRUE") print("ok")
can some one help me in understanding the logic behind the code execution?
My understanding is that "if statement" will execute when the conditional expression is true.
In the above code, I have given character as input, but the if condition is executed, which surprise me.
R converts the argument of if statement if it is interpretable as logical. In this case "TRUE" is interpretable as logical. Please see that as.logical("TRUE") returns TRUE. However, if("HELLO") print("ok") would not work and you will get the error:
Error in if ("HELLO") print("ok") :
argument is not interpretable as logical
You just need to fix the error in your syntax. Try this:
if (TRUE){
print("ok")
}
When I'm in the debugger (from a browser statement for ex.), if I find the code that gives an error, R exits the debugger. But I want to stay in it. How can I do that automatically (e.g. I don't want to manually have to remember to reset option(error) to something when I'm in the debugger.
You can use options(error = recover). This will exit the debugging session and immediately offer to enter a new one, with variables as they were at the time of the error.
For example,
options(error = recover)
myfun <- function(x) x + "a" ; debug(myfun) ; myfun(2)
This leads to the following interactive lines:
debugging in: myfun(2)
debug: x + "a"
Browse[2]> n
Error in x + "a" (from #1) : non-numeric argument to binary operator
Enter a frame number, or 0 to exit
1: myfun(2)
Selection: 1
Browse[3]> ls()
[1] "x"
Browse[3]> print(x)
[1] 2
Browse[3]>
To make this happen automatically, just put the options(error=recover) call as a default for the session.
Your problem may be due to a misunderstanding about the levels of debug. If, for example, you execute debug(myfunc); myfunc(...) , and myfunc calls some other function, then the called function is not in debug mode. If that function throws an error, R quite properly exits the entire environment. Imagine if it didn't: what would happen during non-debug mode?
One solution is: after entering myfunc in debug mode, and you know what called function throws the error, to execute debug(that_func) so you can follow its error path.
Another workaround is to manually enter the offending function call at the debug prompt (instead of hitting RETURN to have the debugger run the next line of your code). In this way, you'll get the error message back but since it was user-called rather than actually executing a line of the code being debug-run, the debugger will not exit.
Please feel free to comment if this is unclear.
Sometimes R throws me errors such as
Error in if (ncol(x) != 2) { : argument is of length zero
with no additional information, when I've written no such code. Is there a general way for finding which function in which package causes an error?
Since most packages come compressed, it isn't trivial to grep /usr/lib/R/library.
You can use traceback() to locate where the last error occurred. Usually it will point you to a call you make in your function. Then I typically put browser() at that point, run the function again and see what is going wrong.
For example, here are two functions:
f2 <- function(x)
{
if (x==1) "foo"
}
f <- function(x)
{
f2(x)
}
Note that f2() assumes an argument of length 1. We can misuse f:
> f(NULL)
Error in if (x == 1) "foo" : argument is of length zero
Now we can use traceback() to locate what went wrong:
> traceback()
2: f2(x) at #3
1: f(NULL)
The number means how deep we are in the nested functions. So we see that f calls f2 and that gives an error at line 3. Pretty clear. We could reassign f with browser placed just before the f2 call now to check it's input. browser() simply allows you to stop executing a function and look around in its environment. Similar to debug and debugonce except that you don't have to execute every line up until the point you know something goes wrong.
Just to add to what #SachaEpskamp has already suggested, setting options(error=recover) and options(show.error.locations=TRUE) can be extremely helpful when debugging unfamiliar code. The first causes R to launch a debugging session on error, giving you the option to invoke the browser at any point in the call stack up to that error. The second option will tell R to include the source line number in the error.