4 ms·

Using String as an example error type seems like a bad choice if nobody actually uses it in practice, though -- it's just leading you down the garden path. Per

by pm215 9y ago

Using String as an example error type seems like a bad choice if nobody actually uses it in practice, though -- it's just leading you down the garden path. Personally I found the error handling section of the documentation confusing and frustrating -- it works through three or four different approaches pointing out issues with them as it goes, and it's hard to tell when it's discussing a simple-but-wrong approach as motivation for the following more-complex-but-correct one, and when it's actually recommending you use the approach. Plus it finishes with an approach with nice properties but an awful lot of boiler plate conversion code, which left me thinking 'surely there must be a better way'. IMHO the error handling section of the rust docs should describe just one way to do things, and it should be the standard way everything uses so your code interoperates with library errors nicely, and that way should not require writing a page of boilerplate just to say 'my function might return an error from library foo or one from library bar or this error of its own'. (If error-chain is that one right way then it should be in the standard library and the documentation.) As it is it looks like 'this language isn't finished yet, come back in six months to see if it's any better' :-(

burntsushi 9y ago
The reason why I wrote it that way was to motivate why error handling is the way it is. I personally think it's hard to just throw the "right answer" at someone and hope they get it, because error handling isn't some rote process you can just plow through. It's important to understand the case analysis involved so that you can choose the right granularity of error handling for your task. All of the error handling strategies in that chapter are interoperable to some degree (with perhaps "panic on error" being the odd duck out). They aren't incompatible philosophies. With that said, thank you for the feedback. When I circle back around to it, I'll make sure to put more emphasis on The Right Way. The conclusion already has some of it, and the case study is supposed to show the progression in action, but perhaps more is needed. I will let others focus on more targeted advice, since one huge chapter on error handling is only part of the story. The purpose of the error handling chapter is start with someone who might not even know what `Option<T>` is, and take them all the way through `try!`, the `Error` trait and automatic `From` conversions from first principles. More than that, it's supposed to teach you why using `String` or `Box<Error>` for your error type can be bad, even if it is ludicrously convenient. Rust is a young language. I expect error handling idioms to evolve. Evolution doesn't mean something isn't ready to be used, because all languages evolve in some way.

by pm215 9y ago

burntsushi 9y ago

The reason why I wrote it that way was to motivate why error handling is the way it is. I personally think it's hard to just throw the "right answer" at someone and hope they get it, because error handling isn't some rote process you can just plow through. It's important to understand the case analysis involved so that you can choose the right granularity of error handling for your task. All of the error handling strategies in that chapter are interoperable to some degree (with perhaps "panic on error" being the odd duck out). They aren't incompatible philosophies. With that said, thank you for the feedback. When I circle back around to it, I'll make sure to put more emphasis on The Right Way. The conclusion already has some of it, and the case study is supposed to show the progression in action, but perhaps more is needed. I will let others focus on more targeted advice, since one huge chapter on error handling is only part of the story. The purpose of the error handling chapter is start with someone who might not even know what `Option<T>` is, and take them all the way through `try!`, the `Error` trait and automatic `From` conversions from first principles. More than that, it's supposed to teach you why using `String` or `Box<Error>` for your error type can be bad, even if it is ludicrously convenient. Rust is a young language. I expect error handling idioms to evolve. Evolution doesn't mean something isn't ready to be used, because all languages evolve in some way.