Re: srfi-18 requirements

[Neil Jerram]

"Julian Graham" <address@hidden> writes:

>> Yes, I'd prefer, if that's not too much work (but in this case you may
>> want to really use SRFI-34 and SRFI-35 rather than hand-write things
>> like "(throw 'srfi-34 ...)").
>
> Right, that's actually what I was trying to do, except that I've
> discovered that SRFI-34 implements 'with-exception-handler' using
> 'lazy-catch', which rethrows caught exceptions after it calls the
> handler.  What's the rationale for this behavior (SRFI-34's or
> lazy-catch's)?

lazy-catch rethrows because otherwise we can't provide a guarantee of
reasonable behaviour to someone who writes code that calls `error' or
`throw' somewhere.  In such situations, the coder should be able to
assume that execution won't just continue normally past that call.

If a lazy-catch handler returned normally, and libguile didn't do a
rethrow itself (as it does now), that (execution continuing normally)
is what would happen.

This was hardly ever a problem in practice, because the usage pattern
for lazy-catch was almost always that the lazy-catch handler would
rethrow to a non-lazy catch just outside the lazy-catch.  But we
(Marius and I) thought it would make sense to enforce the
non-returnability of the lazy-catch handler, by having libguile do the
rethrow itself if the handler doesn't do a non-local exit.  It also
gave a minor bonus of meaning that lazy-catch handler code no longer
has to do the rethrow itself.

The thing that actually triggered all this was me working on SRFI-34,
and then noticing an inconsistency in how lazy-catch works - i.e. that
all the dynamic context apart from the stack (e.g. fluids) is unwound
before the handler is called - and then adding `with-throw-handler',
to provide a mechanism to allow the handler _really_ to be called in
the full dynamic context of the error.  I'm not sure now if the
details of this strictly required libguile performing a rethrow, but
it made good sense at the time.

Moving on to SRFI 34, and how that relates to your question about
rethrowing...  The reference implementation calls `error' if a handler
returns normally, which is like rethrowing in that it forces a
non-local exit.  Also note that in all the examples, the handler uses
call/cc to do a jump, and so does not return normally.

Well, I'm afraid that ended up being a bit rambly.  Did it answer your
question though?

         Neil