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 > > > >______________________________________________ > >[email protected] mailing list > >https://stat.ethz.ch/mailman/listinfo/r-devel > > > ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
