On 20/10/2012 4:19 AM, Matthieu Monrocq wrote:
> This seems heavily influenced by Lisp's Conditions & Restarts[1] (not
> that I have used Lisp before though, but I *am* interesting in error
> handling strategies),
Similar. A bit less involved. But yes. Resumable at-site condition
systems have a relatively long parallel history to exception
(throw/unwind/catch) systems. Conditions in Dylan and CL, Signals in
Mesa, Conditions in PL/I, etc.
> At the moment you only show the first 2, and it's unclear to me exactly
> how the handler is *used* at the call site (looks to me like a regular
> function call passing an instance of T as argument and getting a U in
> exchange). I suppose it would something like:
>
> let u = core::condition::signal(OutOfKitten, t)
More like "let u = OutOfKittens.raise(t)";
OutOfKittens is a const struct of type Condition<T,U>, with methods like
'raise' impl'ed for that struct.
> As such, I would have a tiny request:
>
> => Would it make sense to just make it a "point of customization" but
> have a way to specify a default result in case there is no handler, or
> even specify a default handler ?
Yeah, I haven't added an API point for this yet but was assuming we'd
have such a raise-variant. The raise-point can also just explicitly
probe the condition to see if it has a handler, or manually fetch the
handler itself.
Does "do OutOfKittens.raise_or_else(t) { ... }" work? Or
"OutOfKittens.raise_with_default(t, d)"?
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
