Try an expression with condition handlersSource:
try_fetch() establishes handlers for conditions of a given class
"message", ...). Handlers are functions
that take a condition object as argument and are called when the
corresponding condition class has been signalled.
A condition handler can:
Recover from conditions with a value. In this case the computation of
expris aborted and the recovery value is returned from
try_fetch(). Error recovery is useful when you don't want errors to abruptly interrupt your program but resume at the catching site instead.
# Recover with the value 0 try_fetch(1 + "", error = function(cnd) 0)
Rethrow conditions, e.g. using
abort(msg, parent = cnd). See the
abort(). This is typically done to add information to low-level errors about the high-level context in which they occurred.
Inspect conditions, for instance to log data about warnings or errors. In this case, the handler must return the
zap()sentinel to instruct
try_fetch()to ignore (or zap) that particular handler. The next matching handler is called if any, and errors bubble up to the user if no handler remains.
tryCatch() catches conditions (discarding any running
code along the way) and then calls the handler,
calls the handler with the condition on top of the currently
running code (fetches it where it stands) and then catches the
return value . This is a subtle difference that has implications
for the debuggability of your functions. See the comparison with
tryCatch() section below.
An R expression.
dynamic-dots> Named condition handlers. The names specify the condition class for which a handler will be called.
A stack overflow occurs when a program keeps adding to itself until the stack memory (whose size is very limited unlike heap memory) is exhausted.
# A function that calls itself indefinitely causes stack overflows f <- function() f() f() #> Error: C stack usage 9525680 is too close to the limit
Because memory is very limited when these errors happen, it is not
possible to call the handlers on the existing program stack.
Instead, error conditions are first caught by
try_fetch() and only
then error handlers are called. Catching the error interrupts the
program up to the
try_fetch() context, which allows R to reclaim
The practical implication is that error handlers should never
assume that the whole call stack is preserved. For instance a
trace_back() capture might miss frames.
Note that error handlers are only run for stack overflows on R >=
4.2 (unreleased at the time of writing). On older versions of R the
handlers are simply not run. This is because these errors do not
inherit from the class
stackOverflowError before R 4.2. Consider
tryCatch() instead with critical error handlers that need
to capture all errors on old versions of R.
in a single function. It reproduces the behaviour of both calling
and exiting handlers depending the on the return value of the
handler. If the handler returns the
zap() sentinel, it is taken
as a calling handler that declines to recover from a condition.
Otherwise, it is taken as an exiting handler which returns a value
from the catching site.
The important difference between
that the program in
expr is still fully running when an error
handler is called. Because the call stack is preserved, this makes
it possible to capture a full backtrace from within the handler,
e.g. when rethrowing the error with
abort(parent = cnd).
try_fetch() is more similar to (and implemented on