"Julian Graham" <[EMAIL PROTECTED]> 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
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
