This code seems wrong... what if an error occurs as part of the call to
`copy()`, for example?
As a kind of experience report, I have been using `result` types for
those parts of the compiler where errors must be recoverable rather than
just being reported to the user and papered over. I have found it's
pretty nice except that writing
first_thing().chain { |res1|
second_thing().chain { |res2|
ok(infallible_combination_of(res1, res2))
}
}
gets a little old and induces horrible rightward drift. A macro along
the lines of Haskell's do notation would address this:
#do {
let res1 = first_thing();
let res2 = second_thing();
infallible_combination_of(res1, res2)
}
In general it seems there are three classes of errors
- globally unrecoverable (just call `fail`)
- locally unrecoverable (return a `result<X,Y>` type)
- recoverable (pass in handler or error reporter)
Globally unrecoverable means that the whole task cannot continue (this
is clearly not appropriate for libraries). Locally recoverable means
that some subset of the program must abort, but some outer handler could
possibly catch it. Recoverable means that it's the sort of error where
the procedure could carry on, but the caller may still want to know
about it. These two are suitable for general purpose libraries,
depending on the case. We certainly use all three in the compiler,
though primarily the first and the third.
This whole scheme isn't terribly composable, though. Code must be
written differently depending on whether it may abort due to errors and
so forth. This is precisely what exceptions were aiming to solve, I
suppose (Java's checked exceptions representing a kind of middle
ground). It may be that error propagation is too important to be
papered over entirely, though.
Niko
On 5/29/12 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
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
