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
On Wed, 20 Nov 2002 Mark.Bravington@csiro.au wrote:> 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. >One way to handle this is to wrap the result, something like j <- try( list(value = eval( i, envir=envir))) if( inherits( j, 'try-error')) <<...>> ... return(j$value) luke -- Luke Tierney University of Iowa Phone: 319-335-3386 Department of Statistics and Fax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke@stat.uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
Thanks Luke!-- a succinct and unimproveable solution. cheers 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 #-----Original Message----- #From: Luke Tierney [mailto:luke@stat.uiowa.edu] #Sent: Wednesday, 20 November 2002 2:40 PM #To: Mark.Bravington@csiro.au #Cc: r-devel@stat.math.ethz.ch #Subject: Re: [Rd] restart # # #On Wed, 20 Nov 2002 Mark.Bravington@csiro.au wrote: # #> Dear group #> #> I use "restart" in part of my code, in a way that's not #easily changed to #> "try". << snipped >> #> #> 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. << snipped >> #> # #One way to handle this is to wrap the result, something like # # j <- try( list(value = eval( i, envir=envir))) # if( inherits( j, 'try-error')) <<...>> # ... # return(j$value) # #luke # #-- #Luke Tierney #University of Iowa Phone: 319-335-3386 #Department of Statistics and Fax: 319-335-3017 # Actuarial Science #241 Schaeffer Hall email: luke@stat.uiowa.edu #Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu #