pdd23: closure vs. continuation
Chip Salzenberg
was better to make handlers continuations or closures. She said it was not
important, and to choose whichever is faster. However, I think I erred in
choosing continuations.
In the continuation model (as in pdd23 at present), the exception handler
runs _outside_ the dynamic scope where the exception occurred, which means
that dynamically scoped state required to describe, diagnose, or fix the
exception is not available.
"Oops."
Allison, if you give me the OK, I'll recast pdd23 in the alternative way I
had in mind, where:
* exception handlers are closures,
* the closures are called _inside_ the dynamic scope where the throw occurred,
* a closure returning without executing C<caught> implies "I didn't handle
it, try the next handler",
therefore obviating the "rethrow" opcode.
PS: "caught" will perhaps be better renamed "handled".
--
Chip Salzenberg <ch...@pobox.com>
Bob Rogers
Date: Fri, 30 Jun 2006 22:11:39 -0500
. . .
Allison, if you give me the OK, I'll recast pdd23 in the alternative way I
had in mind, where:
* exception handlers are closures,
* the closures are called _inside_ the dynamic scope where the throw
occurred,
* a closure returning without executing C<caught> implies "I didn't handle
it, try the next handler",
therefore obviating the "rethrow" opcode.
PS: "caught" will perhaps be better renamed "handled".
--
Chip Salzenberg <ch...@pobox.com>
I'm still trying to catch up, but IMHO, this is all to the good.
-- Bob
Allison Randal
>
> Allison, if you give me the OK, I'll recast pdd23 in the alternative way I
> had in mind, where:
>
> * exception handlers are closures,
>
> * the closures are called _inside_ the dynamic scope where the throw occurred,
>
> * a closure returning without executing C<caught> implies "I didn't handle
> it, try the next handler",
> therefore obviating the "rethrow" opcode.
Thumbs up.
> PS: "caught" will perhaps be better renamed "handled".
Agreed.
Allison