i=14
l=8
if(i>l){q()}
print(i)
print(l)
above code is what I simplfied and when I run code above, it ends up with " R session aborted. R encountered a fatal error"
pls advise me way to avoid this error
Calling q() inside an if block from a script in the editor pane of RStudio crashes my RStudio in a similar manner, with a fatal error dialog box. I suspect this is an RStudio bug and should be reported if it recurs with the latest RStudio.
Just putting q() in a script not in an if block quits RStudio as expected, without error messages.
The correct way to terminate a script without killing R in any way is to use stop("why").
if(1>0)stop("am stopping")
print("No")
Related
Error: no more error handlers available (recursive errors ) invoking 'abort' restart
Error: option error has NULL value
whenever I try running any piece of code in R markdown. I didn't have any issues using R markdown last week. The only thing between then and now is that I ran a lot of data analysis on very large data frames(16M points) in another R script, which gave multiple warnings() which I ignored. Does that have anything to do with it? I quit Rstudio, tried restarting, tried clearing garbage with gc() but nothing works. Can't find much on this error on google.
I am asking this question out of curiosity. I have noticed that whenever I boot R, the instance starts up with this error message
As you can see, R boots with the error message "object 'a' not found" Is there any reason for this?
R reads and executes several files at startup, most prominently the ~/.Rprofile file (That is, the file .Rprofile in your home directory). Check these files to see if they contain anything weird.
You can quickly check whether .Rprofile is the culprit by running R with the --vanilla command line argument: this argument prevents the user profile to be read, thus the error should vanish.
Let suppose there is a simple R script with only one statement:
q()
Using the R Script plugin in Pentaho Kettle/Spoon, executing the above R script causes Spoon/Kettle to crash.
How can we stop Kettle/Spoon from crashing abnormally with the above statement in our R script?
Kettle should instead stop executing the script and execution control should return to Kettle.
Try to use a return(value) instead q() to expect kettle handle the value from R script and continue the common kettle row flow.
I've tried to run command in R 2.15.2
rsaga.geoprocessor(lib="ta_channels", module=0, param=list(ELEVATION="DEMflt.sgrd", CHNLNTWRK=paste("channels", i, ".sgrd", sep=""), CHNLROUTE="channel_route.sgrd", SHAPES="channels.shp", INIT_GRID="DEMflt.sgrd", DIV_CELLS=3, MINLEN=40), show.output.on.console=FALSE)
and I'm constantly getting this warning:
Warning message:
running command '"C:/Users/Nenad/Documents/R/win-library/2.15/RSAGA/SAGA-GIS/saga_cmd.exe" ta_preprocessor 2 -DEM "DEM1.sgrd" -RESULT "DEMflt.sgrd" -MINSLOPE "0.05"' had status 1
I use windows 8 and also tried to ran R as admin.
Any idea what is the problem? Thanks!
Idk how actual it is, but I've been struggling with "had status 1" warning a lot. Especially it got really annoying when I tried to use seasonal package to conduct the X13-ARIMA-SEATS seasonal decomposition of time series. The seasonal::seas command just didn't work, because in the code of this command there is a stop condition when running a certain stuff with cmd.exe returns non-zero status. While, as it was mentioned before, 'status 1' doesn't prevent command execution, in case of seasonal package it does.
The problem in my case was caused by some mistake in Windows Registry (Win 10), that in turn caused warning System cannot find the path specified when launching CMD.exe or PowerShell, which caused warning inside R as well. So to fix it:
Press Win+R -> regedit
In HKEY_CURRENT_USER\SOFTWARE\Microsoft\Command Processor folder clean the value of Autorun record (it should be empty)
Do the same for Autorun in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor
After these actions annoying warning with "has status 1" has gone and seasonal::seas started to work perfectly.
Hope it will be usefull for somebody.
Running system commands from R can be really tricky. In my experience, as long as the exit code is not 127 then the command did run, and you could use the intern=TRUE switch in the system command for a more verbose output. If you run the command again, the warning message could contain a errmsg attribute as well for some more info. hth
I've often been frustrated by R's cryptic error messages. I'm not talking about during an interactive session, I mean when you're running a script. Error messages don't print out line numbers, and it's often hard to trace the offending line, and the reason for the error (even if you can find the location).
Most recently my R script failed with the the incredibly insightful message: "Execution halted." The way I usually trace such errors is by putting a lot of print statements throughout the script -- but this is a pain. I sometimes have to go through the script line by line in an interactive session to find the error.
Does anyone have a better solution for how to make R error output more informative?
EDIT: Many R-debugging things work for interactive sessions. I'm looking for help on command-line scripts run through Rscript. I'm not in the middle of an R session when the error happens, I'm at the bash shell. I can't run "traceback()"
Try some of the suggestions in this post:
General suggestions for debugging in R
Specifically, findLineNum() and traceback()/setBreakpoint().
#Nathan Well add this line sink(stdout(), type="message") at the beginning of the script and you should get in console message both script content and output along with error message so you can see it as in interactive mode in the console. (you can then also redirect to a log file if you prefer keeping the console "clean")
Have a look at my package tryCatchLog (https://github.com/aryoda/tryCatchLog).
While it is impossible to improve the R error messages directly you can save a lot of time by identifying the exact code line of the error and have actual variables at the moment of the error stored in a dump for "post mortem" analysis!
The main advantages of the tryCatchLog function over tryCatch are
easy logging of errors, warnings and messages into a file or console
warnings do not stop the program execution (tryCatch stops the execution if you pass a warning handler function)
identifies the source of errors and warnings by logging a stack trace with a reference to the source file name and line number (since traceback does not contain the full stack trace)
allows post-mortem analysis after errors by creating a dump file with all variables of the global environment (workspace) and each function called (via dump.frames) - very helpful for batch jobs that you cannot debug on the server directly to reproduce the error!
This will show a more detailed traceback, but not the line number:
options(error = function() {traceback(2, max.lines=100); if(!interactive()) quit(save="no", status=1, runLast=T)})
One way inside a script to get more info on where the error occurred is to redirect R message to the same stream as errors :
sink(stdout(), type="message")
This way you get both messages and errors in the same output so you see which line raised the error...