On 19/03/2012 3:59 AM, Daniel Farina wrote:
Relatedly, and more complicated-ly, what is Rust idiom for dealing
with cases where a high-level chunk of code wants to be able to
dictate the error handling method in a lower-level function?
I think a good example of this is given in a chapter of "Practical Common Lisp":
http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html
CL's flavor of "exception" handling is probably the only one I've
found gave me sufficient control comparable to rolling my own
constructs in a C program, checking everything at the lowest levels of
execution with maximum information without being as laborious.
Hi,
We get this question somewhat regularly and the short-short answer is
"we're still likely to revisit this, in the sense of adding new mechanisms".
The longer answer is that we're familiar with the CL condition system as
well as a number of alternatives, and need to spend some time exploring
to find what "fits" the Rust semantics best. I spent quite a while
sketching, prototyping and researching this aspect of the language
before getting started, and wound up adopting a "wait and see" approach,
letting other language features mature first. It's a complicated topic
and there's a lot to say. To summarize where my thinking on it is _now_,
it's something like so:
- The CL system is overengineered (separated handle vs. restart)
- Try/catch is underengineered (no at-site handling)
- Rust's current system is an attempt to copy Joe Armstrong's advice
and the "crash only design" papers, that is, magnifying faults to
subsystem boundaries to make error handling uniform and testable.
- I acknowledge that even in Erlang this didn't _quite_ hold up and
they wound up growing 2 other not-great error handling systems.
Dogma often falls down in the face of pragmatics.
- We have a few reasons to want to keep unwinding-unwinding --
actually throwing away frames -- as idempotent and unrecoverable,
killing a task rather than "catching". But that's not to say that
we can't have at-error-site handler options.
- I'm interested, willing, and likely to experiment with some kind
of dynamic-scope handler scheme in the 0.3-0.4 timeframe.
- The last sketch of my current plan was "revive an earlier form
of a condition system Rust used to have based on Mesa's system",
as I discussed back in November, in the middle of this email:
https://mail.mozilla.org/pipermail/rust-dev/2011-November/000999.html
I'm still slightly unsure if this is necessary -- nobody's modified the
os library to "take flags describing recovery options" yet -- nor am I
sure that this signal/handle system will be enough moving parts to
capture the 80-90% case of minor-error-handling. Nor am I sure that it's
best built on this primitive rather than, say, a more general concept of
a dynamically-scoped module-level global (like CL *special-variables*)
but I think a lot of the implementation machinery for the latter would
be recycled between features anyways, so I think I'll start with "just"
conditions and see how it goes.
Hth, happy to talk more but recognize that it's a big design-space,
nobody's solved it "correctly" yet, each solution is somewhat
language-specific, and such threads tend to go on ad infinitum...
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
