[r6rs-discuss] guard re-raising and continuable exceptions
derick.eddington at gmail.com
Sat Jul 12 14:58:45 EDT 2008
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.
On Wed, 2008-07-09 at 07:59 -0700, Derick Eddington wrote:
> A recent discussion on the plt-scheme mailing list  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?
>  http://list.cs.brown.edu/pipermail/plt-scheme/2008-July/025807.html
More information about the r6rs-discuss