"try"ing to understand condition handling

Since you have not told us what 'the documents' are (and only vaguely 
named one), do you not think your own documentation is inadequate?

There are documents about the condition system on developer.r-project.org: 
please consult them.

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)

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