On Sat, Nov 19, 2011 at 11:41:13AM -0800, Graydon Hoare wrote:
> Yes, and I am proposing one: pass *in* your handlers (or symbolic codes
> indicating handler-strategy) and have the callee handle *at the site of the
> condition*. Sorry if I wasn't clear enough about the implied use of tags I
> meant, up-thread.
> The old Rust condition system was modeled on the condition system in Mesa.
> You named "signals" as global items and gave a syntactic form to routing a
> given signal to a locally-defined "handler" in the caller, much as you
> would a try/catch block. The difference is that a handler in this scheme is
> a typed function-like definition dangling after the protected block. It
> reads like so:
I may not be understanding this correctly, but it seems to have
security implications by breaking encapsulation. The caller-supplied
handler will have access to values at the exception site that the
caller would not normally be able to see.
Further, code has no way to prevent this from happening. It can
define its own handlers for all known conditions to dynamically shadow
any defined by its caller, but it can't anticipate new conditions
defined in later versions of functions it calls.
[Snip]
> So I removed the condition system from the design docs, and never
> implemented it. I propose structuring the libraries along these lines. That
> is, to have the callee authors actually think a bit about what an
> unusual-return means, which ways there might plausibly be for recovering
> from it, and take a tag or vec-of-tags carrying the preferred recovery
> strategy.
> If this fails to hold together and we really, really have to revive some
> kind of structured at-a-distance recovery system, I'm going to suggest
> going back to the Mesa-like signal scheme I sketched out earlier (and
> above). The main (substantial!) advantage it offers is that recovery paths
> cause no actual unwinding-or-destruction -- recovery occurs effectively "at
> the signal site" -- so there's no question of perturbation of the
> typestate. Unwinding still only happens during failure. The handler is
> invoked like any other function and if it succeeds the unwinder is never
> even involved. IMO it's much tidier than try/throw/catch and/or
> monads-by-macros.
Jeff Schultz
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
