I also find the repeatition of unwrap all over the code being quite nasty Most of the time the result is just unwrapped without taking into account the error case, so i think the usage of Option or Result useless.
I think a good solution exits and can make the code more maintainable, and easier to read. There should not have all these unwrap (or get) call for code we know it cannot fails, because the necessary check has been done earlier. I am in favor of two version of the api: from_str which has already done the unwrap, and a from_str_safe for instance that returns a Result or option. Or perhaps allow the propagation of Option/Result. Le 7 déc. 2013 01:03, "Daniel Micay" <danielmi...@gmail.com> a écrit : > On Fri, Dec 6, 2013 at 7:00 PM, Palmer Cox <palmer...@gmail.com> wrote: > > Why not use Result instead of Option for these types of things? Result is > > already defined to be able to return error codes using Err. The only way > to > > indicate an error when returning an Option is to return None which > doesn't > > allow for that. Also, IMO, None doesn't necessarily mean "error" to me. > Lets > > say we have a function defined as: > > > > fn do_something(value: Option<~str>); > > > > It seems like it would be much to easy to accidentally write something > like: > > do_something(str::from_utf8(...)) which might result in the error being > > hidden since do_something might not consider None to be an error input. > > > > -Palmer Cox > > If there's only one reason it could fail, then `Option` is the > idiomatic way to report the error case. It's exactly what `Option` is > used for. A stack trace can report where the error occurred if you > decide to ignore the error case and use `unwrap` (or `get`, if it's > renamed). > _______________________________________________ > 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
