From Mark.Bravington@csiro.au  Wed Nov 20 02:50:47 2002
From: Mark.Bravington@csiro.au (Mark.Bravington@csiro.au)
Date: Wed, 20 Nov 2002 13:50:47 +1100
Subject: [Rd] restart
Message-ID: <A8877251964B294BAB5BA1FC58B43FED025B4398@molly.tas.csiro.au>

Dear group

I use "restart" in part of my code, in a way that's not easily changed to
"try". As I convert code from R1.5.0 to R1.6.1, I'm getting ugly messages;
the help system says to contact r-devel, so here I am. This one's a bit
complicated-- sorry!

The context is inside a debugger (I have an R and S debugger that offers
stand-alone code windows, line numbered conditional breakpoints,
statement-skipping, and graceful error trapping). I use the following
function to trap errors, both in code undergoing debugging, and in the
user's interactions with the debugger:

eval.catching.errors <- function(i, envir) do.in.envir( envir=find.debug.HQ(
FALSE), {
  if(.evaluated.OK.) {
    .evaluated.OK. <<- FALSE
    restart(TRUE)
    j <- eval( i, envir=envir)
    .evaluated.OK. <<- TRUE
return(j) }
  else
return(NULL)
})

The function is a bit opaque because I have fiddled with the lexical
scoping, but the rationale is fairly simple. There is a 'global flag' called
".evaluated.OK." which is normally set to TRUE. When "eval.catching.errors"
is called, the flag is reset to FALSE and there's an attempt to evaluate the
expression given in "i". If there are no errors in evaluation, then the
global flag is reset to TRUE before "eval.catching.errors" exits. Otherwise,
"eval.catching.errors" is reinvoked (thanks to "restart" catching the error)
and exits with the global flag set to FALSE. Subsequent debugger code
inspects the status of the global flag to decide what happens next.

The problem with changing 

  restart( TRUE)
  j <- eval( i, envir=envir)

into

  j <- try( eval( i, envir=envir))
  if( inherits( j, 'try-error')) <<...>>

is that the statement being debugged may itself be a call to "try" which
happens to fail. In that case, the debugger would stop and report an error,
whereas the code-being-debugged has actually been designed to run smoothly
in the event of error. Under R1.5.0, errors that occur within a "try"
statement in the code-being-debugged are (correctly) not flagged as problems
by my debugger.

I can hack my way round this with a call to .Internal( restart( on)), but
it's not pretty and I worry about what will happen if error-trapping
mechanisms are changed in future.

Thanks for any advice

Mark


*******************************

Mark Bravington
CSIRO (CMIS)
PO Box 1538
Castray Esplanade
Hobart
TAS 7001

phone (61) 3 6232 5118
fax (61) 3 6232 5012
Mark.Bravington@csiro.au



[Rd] restart
Mark.Bravington@csiro.au