From luke at stat.uiowa.edu  Tue Feb 20 20:15:25 2007
From: luke at stat.uiowa.edu (Luke Tierney)
Date: Tue, 20 Feb 2007 13:15:25 -0600 (CST)
Subject: [Rd] "try"ing to understand condition handling
In-Reply-To: <20070220174113.GB5871@wheat.betterworld.us>
References: <20070219224141.GA21040@wheat.betterworld.us>
	<Pine.LNX.4.64.0702200725490.1805@gannet.stats.ox.ac.uk>
	<20070220174113.GB5871@wheat.betterworld.us>
Message-ID: <Pine.LNX.4.64.0702201312050.30864@nokomis.stat.uiowa.edu>

On Tue, 20 Feb 2007, Ross Boylan wrote:

> 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,

Currently interrupts cannot be handled in a way that allows them to
continue at the point of interruption.  On some platforms that is not
possible in all cases, and coming close to it is very difficult.  So
for all practical purposes only tryCatch is currently useful for
interrupt handling.  At some point disabling interrupts will be
possible from the R level but currently I believe it is not.

Best,

luke

>
>>
>> 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
>>>
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-- 
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:      luke at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu



[Rd] "try"ing to understand condition handling
Luke Tierney