On Error Handling in Rust
lucumr.pocoo.org
On Error Handling in Rust
1–10 of 82 posts
Re: On Error Handling in Rust
#2For those who don't closely follow the topic of language design, error handling is actually a fascinatingly diverse subject. Exceptions are not the end of the story, and it's great to see languages explore this space.
Microsoft's upcoming M# language has also teased an interesting approach to error-handling. I'm very curious to see what they come up with.
Re: On Error Handling in Rust
#3Wow, I really, really like that `?` operator idea. I haven't quite dived into Rust yet (I'm watching and waiting for v1.0), but I would be really excited to work with a language that makes error handing so easy and safe.
Re: On Error Handling in Rust
#4The nicest things about error handling in this manner are that any function that has a error condition makes it clear in the function signature, and any time you call a function that can fail, it's visible in the source where you make the call.
This makes it very easy to tell whether code is handling potential failure conditions or ignoring them - you're either ignoring the return value (which is a compiler warning) or you're handling the failure condition. I'm reminded of Raymond Chen's post from 2005 about handling failure conditions, and recognizing code which handles all of its error conditions:
http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...
I think this approach will pay great dividends in both understandability and readability.
Re: On Error Handling in Rust
#5So it's a specialized mapping operator for the Result functor. Why restrict it to Result only? What about using option to denote a failure condition without a specific reason? Or other kinds of interesting functors?
Re: On Error Handling in Rust
#6[deleted]
Re: On Error Handling in Rust
#7The Rust RFC[1] linked in the article is also super neat; it looks basically like a way to build a checked-exceptions like syntax in a way that meshes naturally with Rust's existing semantics and types, as well as the ? operator presented in the blog post.
[1] https://github.com/glaebhoerl/rfcs/blob/trait-based-exceptio...
Re: On Error Handling in Rust
#8So it's a specialized mapping operator for the Result functor. Why restrict it to Result only? What about using option to denote a failure condition without a specific reason? Or other kinds of interesting functors?
Check out the RFC linked from the article for some thoughts on that:
https://github.com/glaebhoerl/rfcs/blob/trait-based-exceptio...
Re: On Error Handling in Rust
#9The nicest things about error handling in this manner are that any function that has a error condition makes it clear in the function signature, and any time you call a function that can fail, it's visible in the source where you make the call. This makes it very easy to tell whether code is handling potential failure conditions or ignoring them - you're either ignoring the return value (which is a compiler warning)…
It basically feels like Java's checked exceptions without stack unwinding and with a nicer syntax - the possible errors are part of the signature, the compiler insists you do something about them, and there is a wrapping facility to cross system boundaries without leaking details.
In case my comment is taken as denigration, I'm saying this from a perspective of admiration. I think this is a fairly elegant way to solve a difficult problem, and learning Rust has been a true pleasure. I'm excited for the future of the language.
Re: On Error Handling in Rust
#10I hope we get some sugar here, the ? operator is a great idea. I like the trait implementation as well. I think Rust needs multiple dispatch though - a given type needs to support conversions of IOError to different custom results right? So you can use a struct in different library functions that may return a different custom error. Or maybe I am missing something here; but I do believe multiple dispatch is planned for 1.0.
I did this in Haskell using MPTC, I have used the Convertible class like:
instance Convertible IOError RedisError where safeConvert =
Then I have combinators like:
convEither :: Convertible e1 e2 => Either e1 a -> Either e2 a
and
convEitherT :: Convertible e1 e2 => m (Either e1 a) -> EitherT m e2 a
These are quite handy in close quarters combat. For example to open a file and bail on a generic IOException with a custom application exception, I can have something like:
instance Convertible IOException CustomError
getWords :: FilePath -> IO (Either CustomError [String])
getWords fileName = runEitherT $
do file >= convEitherT
line