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
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 > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >-- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
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),unless a handler does a non-local exit, typically by invoking a restart> and withRestarts (I can't tell > where control ends up).at the withRestarts call> 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?If all the available handlers return normally then signalCondition returns. Not odd at all -- analogous to synchronous posix signals. If you don't want this then write a handler that does a transfer of control or write a signaling function that uses signalCondition and provides a default action, i.e. what it does if signalCondition returns, that does a transfer of control, e.g. by invoking an "abort" restart. This is essentially what stop() does.> > 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.All handlers are executed, most recently established first, until there are none left or there is a transfer of control. Conceptually, exiting handlers established with tryCatch execute a transfer of control and then run their code.> 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).Restart names, in the simple forms of withRestarts, are names for points to transfer control to. They are not conditions. They are used by condition handlers to find appropriate points to jump to. You can look at the code for warning() and suppressWarnings() to see an example of how this is used. The tryCatch mechanism is quite simple and adequate for most purposes. The calling handler plus restarts framweork is itended to be rich enough to allow construction of a variety of frameworks, including tryCatch, but this power comes at the cost of added complexity. Hopefully a more extensive document on this will get written in the next few months; for now the notes available off the developer page may be useful. best, luke> > 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 >-- 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