On 5/29/12 4:57 PM, Niko Matsakis wrote: > This code seems wrong... what if an error occurs as part of the call to > `copy()`, for example?
The idea is to simply propagate errors that take place as part of `copy`, in a ML/C++/Java/Haskell manner. [...] > 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. Indeed, I suspect that achieving composability without sacrificing safety or performance is the big issue here. The other problem is that the function may not have enough information to determine what is "locally unrecoverable". I believe that `remove` is a good example of issues whose recoverability depend on the context. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
