On Sat, Oct 20, 2012 at 10:48 AM, Graydon Hoare <gray...@mozilla.com> wrote:
> Some references to the lurking plan here: > https://mail.mozilla.org/pipermail/rust-dev/2011-November/000999.html Firstly, I'd like to express my appreciation for the clear reasoning in this linked post. I found the arguments clear and compelling, matching my own experience -- especially the enumeration of the small set of realistic uses of exception handling (ignore, retry, hard-fail, log, or try one of a small number of alternatives to achieve the desired result). > - Condition.raise is a normal function and does something very simple: > - look in TLS to see if there's a handler > - if so, call it and return the result to the raiser > - if not, fail > > - This means condition-handling happens _at site_ of raising. If > the handler returns a useful value, processing continues as if > nothing went wrong. It's _just_ a rendezvous mechanism for an > outer frame to dynamically provide a handler closure to an inner > frame where a condition occurs. This all seems reasonable after reading that post. > So: API survey. Modulo a few residual bugs on consts and function > regions (currently hacked around in the implementation), I have 3 > different APIs that all seem to work -- which I've given different names > for discussion sake -- and I'm trying to decide between them. They > mostly differ in the number of pieces and the location and shape of the > boilerplate a user of the condition system has to write. My current > preference is #3 but I'd like a show of hands on others' preferences. <snip> > Opinions? Clarifying questions? I prefer option #3. I like that it states the condition and handler up-front (in contrast to most exception-handling syntaxes, that leave you guessing what might go wrong until you reach the catch statements at the end of the try/catch block). I like that the error-handling code is implicitly not an afterthought. (I find that when I'm writing the code on the main path, there's a strong temptation to just "keep on coding", and come back to insert the error-handling code "later".) I like that it has the minimum of boilerplate code (in contrast to option #1 especially). In addition to the boilerplate, I don't really like option #1 because of the separation of the protected block from the handler code. My concern with option #2 is that, despite my general fondness for RAII, the '_g' variable isn't explicitly used anywhere, so creating a named variable seems redundant. Plus, having an object that can reach out of its variable and affect all the code that follows in its block scope is too "magical" for my liking. jb _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
