I apologize for the way I phrased some things I said, because they might come across as argumentative and that was not my intent. I apologize for not clearly stating what I was really trying to get at. What I want to know is: what is the intended interpretation of the R6RS regarding `guard' re-raising exceptions? I want to know this because I want to use continuable exceptions in my libraries which might get used with code which might use `guard'.
Is the intent of the R6RS that `guard' re-raise continuable exceptions so that they remain continuable so that it is possible for the next handler to return to the `raise-continuable'? If so, I request a correction be added to the errata. Or is the intent that `guard' re-raise continuable exceptions so that it is not possible to return to the `raise-continuable'? If so, what is the reason? I searched for insight into this issue but was unable to find any information about it. The formal semantics do not include `guard'. I could not find any mention of this issue in any of: the R6RS documents (including previous drafts) and the errata, the r6rs-discuss and r6rs-editors archives, and the formal comments and responses. The description of `guard' given in the R6RS and the reference implementation of `guard' available at r6rs.org are both straight from SRFI-34, and since SRFI-34 does not include the notion of continuable exceptions, and given the absence of any mention of this issue, I suspect it was forgotten or not realized and so `guard' was not updated. Thank you for your time. Best, -- : Derick ---------------------------------------------------------------- On Wed, 2008-07-09 at 07:59 -0700, Derick Eddington wrote: > A recent discussion on the plt-scheme mailing list [1] caused me to > realize R6RS's `guard' is not specified to re-raise unhandled > continuable exceptions as continuable exceptions. R6RS Libraries 7.1 > says of `guard': "[if none of the `guard' clauses handle the exception] > then `raise' is re-invoked on the raised object within the dynamic > environment of the original call to `raise' except that the current > exception handler is that of the `guard' expression." That clearly says > `raise', but how can `raise' be "re-invoked" and how can there be an > "original call to `raise'" if it was not called in the first place > because `raise-continuable' was originally called? > > Maybe I'm wrong or missing something, but doesn't having `guard' > re-raise using `raise' seriously reduce the usefulness of being able to > raise continuable exceptions? Using `with-exception-handler' with a > handler which re-raises, one can make it re-raise > using `raise-continuable' incase the preceding handler wants to return, > and if the original raise was done with `raise-continuable' this works > like the raiser and the handlers all wanted, and if the original raise > was done with `raise', the &non-continuable exception is raised when > the first handler returns, like the raiser wanted. But if somebody used > `guard' and that `guard' doesn't handle the exception being raised so it > re-raises using `raise' and the exception was originally raised as > continuable so that the handler which does handle it can return to the > raiser, the guard's use of `raise' makes it impossible for the other > handler to return to the raiser because when it returns it's returning > to the guard's `raise' which will cause a separate &non-continuable > exception to be raised. > > I was really starting to like the idea of libraries' procedures being > able to raise-continuable a &warning (or any non-&serious) so that > interested users of a library can install a handler so they can know > about the warnings and decide if they want to return to allow the > program to continue or not, otherwise, by default, the initial/default > exception handler will return for non-&serious exceptions, as the R6RS > specifies, and the program will continue. This seems like a very > attractive use of continuable exceptions to me, but if somebody uses a > `guard' somewhere in between and `guard' re-raises using `raise', it > makes this impossible. (right?) > > If `guard' was instead specified to use `raise-continuable' to re-raise > unhandled exceptions, would that solve this problem and retain > everything else about `guard' and not create any other problems? > > [1] http://list.cs.brown.edu/pipermail/plt-scheme/2008-July/025807.html > _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
