From ross at biostat.ucsf.edu  Tue Feb 20 18:41:14 2007
From: ross at biostat.ucsf.edu (Ross Boylan)
Date: Tue, 20 Feb 2007 09:41:14 -0800
Subject: [Rd] "try"ing to understand condition handling
In-Reply-To: <Pine.LNX.4.64.0702200725490.1805@gannet.stats.ox.ac.uk>
References: <20070219224141.GA21040@wheat.betterworld.us>
	<Pine.LNX.4.64.0702200725490.1805@gannet.stats.ox.ac.uk>
Message-ID: <20070220174113.GB5871@wheat.betterworld.us>

On Tue, Feb 20, 2007 at 07:35:51AM +0000, Prof Brian Ripley wrote:
> Since you have not told us what 'the documents' are (and only vaguely 
> named one), do you not think your own documentation is inadequate?
I mean the command description produced by ?tryCatch.
> 
> There are documents about the condition system on developer.r-project.org: 
> please consult them.
> 
OK, though I would hope the user level documentation would suffice.
> I quess 'ctl-C' is your private abbreviation for 'control C' (and not a 
> type of cancer): that generates an interrrupt in most (but not all) R 
> ports.  Where it does, you can set up interrupt handlers (as the help page 
> said)
> 
My P.S. concerned whether the code that was interrupted could continue
from the point of interruption.  As far as I can tell from ?tryCatch
there is not,

> 
> On Mon, 19 Feb 2007, Ross Boylan wrote:
> 
> >I'm confused by the page documenting tryCatch and friends.
> >
> >I think it describes 3 separate mechanisms: tryCatch (in which control
> >returns to the invoking tryCatch), withCallHandlers (in which control
> >goes up to the calling handler/s but then continues from the point at
> >which signalCondition() was invoked), and withRestarts (I can't tell
> >where control ends up).
> >
> >For tryCatch the docs say the arguments ... provide handlers, and that
> >these are matched to the condition.  It appears that matching works by
> >providing entries in ... as named arguments, and the handler matches
> >if the name is one of the classes of the condition.  Is that right?  I
> >don't see the matching rule explicitly stated.  And then  the handler
> >itself is a single argument function, where the argument is the
> >condition?
> >
> >My reading is that if some code executes signalCondition and it is
> >running inside a tryCatch, control will not return to the line after
> >the signalCondition.  Whereas, if the context is withCallHandlers,
> >the call to signalCondition does return (with a NULL) and execution
> >continues.  That seems odd; do I have it right?
> >
> >Also, the documents don't explicitly say that the abstract subclasses
> >of 'error' and 'warning' are subclasses of 'condition', though that
> >seems to be implied and true.
> >
> >It appears that for tryCatch only the first matching handler is
> >executed, while for withCallHandlers all matching handlers are
> >executed.
> >
> >And, finally, with restarts there is again the issue of how the name
> >in the name=function form gets matched to the condition, and the more
> >basic question of what happens.  My guess is that control stays with
> >the handler, but then this mechanism seems very similar to tryCatch
> >(with the addition of being able to pass extra arguments to the
> >handler and  maybe a more flexible handler specification).
> >
> >Can anyone clarify any of this?
> >
> >P.S. Is there any mechanism that would allow one to trap an interrupt,
> >like a ctl-C,  so that if the user hit ctl-C some state would be
> >changed but execution would then continue where it was?  I have in
> >mind the ctl-C handler setting a "time to finish up" flag which the
> >maini code checks from time to time.
> >
> >Thanks.
> >
> >Ross Boylan
> >
> >______________________________________________
> >R-devel at r-project.org mailing list
> >https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>



[Rd] "try"ing to understand condition handling
Ross Boylan