> > 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).
Since fail can be constrained to a task , its fine to have it in a library task or function designed to be used in a task... > 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. Yep no one disputes that exceptions are better for user code that's easy to read / write but they are still not suitable for systems programming . You could have optional exceptions but not use them in corelib / systems programming/ Cinterop , can exceptions work well with regions ? Ben _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
