Error in doWithOneRestart

Question

I have a longer, complex code (>7000 lines) with many nested functions, each of them enclosed in a separate tryCatch. The code works perfectly except for a "pseudo-error":

Error in doWithOneRestart(return(expr), restart): no function to return from, jumping to top level 

doWithOneRestart() is internal in R as an element of the tryCatch function. I call it "pseudo-error", because the tryCatch should lead to stop() if an error ocurrs and write the error message in a log file. Instead, this "error" is not stopping the program (actually not influencing it at all) and it is shown only on the console and not written into the log file. Usual debugging procedures did not help, because the error is not reproducible (!): it may ocurr at different processing stages of the program. Changing the warning options to 0 or -1 will not help.

Since the program does the job, this error is not critical. But I would like to understand what is happening. Maybe someone has already experienced the same problem, or could come up with an original debugging strategy ...

Update (28.10.2013): I found out where the problem came from. It's linked to a problem with java heap overflow (I was using the xlsx package to read Excel files). Among many other problems: although the connection to the Excel file is closed (definitely!), the system considers it as an unused connection (shown in traceback() ), tries to close it, but finds out it is already closed: you get the "pseudo-error" described above, and never exactly at the same moment (not reproducible). Using the garbage collector gc() at the right place solved the problem. The script is now running stable for several days.

Answer 1

Advice from Peter Dalgaard on R-help .

The easiest way to get that message is to execute return() from the top level:

return(1) 

You might be trying to return() from source() d file. Or maybe source() ing something that was intended to be inside a function body (extraneous '}' characters can do that).

---

The usual debugging strategies should work: calling traceback() after the error, or setting options(error = recover) .