On Wed, May 30, 2012 at 3:41 AM, Graydon Hoare <[email protected]> wrote:
> On 5/29/2012 1:07 AM, David Rajchenbach-Teller wrote: > >> As promised, I have attempted to rewrite my original function |move| >> with a mechanism that would let us define issue-handling policies. This >> mechanism is inspired by both the current thread and the previous thread >> on exceptions, a few months ago. >> >> So far, the result is not too convincing yet, but it can certainly serve >> as a base for improvements: >> https://gist.github.com/**2823196<https://gist.github.com/2823196> >> > > Hi! > > Sorry I've been away, I wanted to talk about this issue, or, well, kinda > just remind you and others in this conversation that there is (in my mind > at least, and in the bug tracker[1]) "a plan" for how to do this. I've been > continuing to assume this is something we'd handle with per-task > dynamic-scoped values, just haven't got around to implementing them yet. > Should be almost entirely library code. > > Here's a sketch of your 'move' function written in this style: > > https://gist.github.com/**1f9c8fe1debd9a504eef<https://gist.github.com/1f9c8fe1debd9a504eef> > > I think a sufficiently gnarly implementation that's allowed to hang a > special-variable list off the side of each task should be able to work > given that, just keying off the different addresses of the various consts > in memory. A bit of a hack but I think it might work. > > Note as discussed earlier, in that example the handling all happens _at_ > the dynamic site of signalling (via a call to a passed-down closure, > accessed through the handler library) not by unwinding. Unwinding still > only happens on failure and is still idempotent, unrecoverable. > > Does this not sit well with you currently? > > -Graydon > > [1] Existing plan: > https://github.com/mozilla/**rust/issues/1945#issuecomment-**4425610<https://github.com/mozilla/rust/issues/1945#issuecomment-4425610> > https://mail.mozilla.org/**pipermail/rust-dev/2011-**November/000999.html<https://mail.mozilla.org/pipermail/rust-dev/2011-November/000999.html> > https://github.com/mozilla/**rust/issues/1857<https://github.com/mozilla/rust/issues/1857> > > ______________________________**_________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> > Hi Graydon, I must admit I really like this script. The typical issues with common errors systems are: - if you need to handle an error code, then at the error site you have precise information on the error, but no information on the context - if you need to handle an exception, then at the catch site you have information on the context but you have lost (due to unwinding) the precise information on the error By injecting closures with the required information on the context, we get the best of both worlds. I seem to recall that Lisp had a similar system (with dynamically scoped handlers), is this where this scheme takes this information from ? My main concern with Lisp was that because the handlers are dynamically scoped, it is difficult to know which handlers may be used by a particular function call or if some handlers were not set. It also requires a RAII construct to automatically reset the handler to its previous value once the current handler is no longer needed. Do you think it would be possible/desirable to instead have the user pass those handlers as arguments to the function, with null default values ? The main benefit is that it documents right in the function which cause of errors it may raise and how to handle them. The main criticism is that it ends being close to "checked exceptions", with the limitation that suddenly adding a new error-handler may require modifying all call sites if not careful (thus the idea of defaulting them) and percolate all through the callers dependencies (though it's their decision to advertise the new handler or not). Of course, the same can be said with exceptions... And it might make sense to have some specific/often required handlers be available through globals to avoid cluttering the interfaces (out_of_memory_err, divide_by_zero_err...) similar to Java's RuntimeException hierarchy which is unchecked. (Users are free to use globals or arguments, obviously) -- Matthieu
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
