31–40 of 63 posts
Also, sometimes just unwrap it. There is some software where it's perfectly fine to panic. If there is no sane default value and there is nothing you can do to recover from the error, just unwrap. Also, sometimes you just write software where you know the invariant is enforced so a type is never None, you can unwrap there too. I find it interesting how a lot of people find Rust annoying because idiomatic Rust is a ve…
Also, sometimes just unwrap it. There is some software where it's perfectly fine to panic. If there is no sane default value and there is nothing you can do to recover from the error, just unwrap. Also, sometimes you just write software where you know the invariant is enforced so a type is never None, you can unwrap there too. I find it interesting how a lot of people find Rust annoying because idiomatic Rust is a ve…
Imo always expect rather than unwrap in those cases. If it's justifiable, you should justify it in the message. ("This should never happen because: ..., if you see this message there's a bug.")
I'm not very familiar with Rust. Do the built in Option and Result types not implement map and flatMap?
Earlier quoted context omitted.
And the same in Python: if user := get_user() is not None: # use user else: # return error Although given the happy path code can mean you don't see the error condition for ages, I much prefer this: if (user := get_user()) is None: # return error # use user
hehehe. reminds me of if err != nil in Go which is really not an issue in my opinion. But it seems to have become somewhat infamous in some circles.
Easily 60-70% of all go code is about propagating errors to the caller directly.
Something I use for situations where nesting is getting out of hand. Probably not idiomatic but, I find it practical in these cases. if param.is_none() { // Handle, and continue, return an error etc } let value = param.as_ref().unwrap(); // or as_mut // Use `value` as normal.
You can rewrite it using let-or-else to get rid of the unwrap, which some would find to be more idiomatic. let value = Some(param.as_ref()) else { // Handle, and continue, return an error etc } // Use `value` as normal.
Something I use for situations where nesting is getting out of hand. Probably not idiomatic but, I find it practical in these cases. if param.is_none() { // Handle, and continue, return an error etc } let value = param.as_ref().unwrap(); // or as_mut // Use `value` as normal.
Any advantages of this over let-else?
Hmm, I kind of disagree. The method literally returns “OK or an error”. It converts an Option into a Result and the name reflects that.
There is something of an inconsistency though, although IMHO it’s worth it. The `Result::ok()` method returns a Some if it’s Ok, and None otherwise, which is concise and intuitive but indeed different from `Option::ok_or`.
Something I use for situations where nesting is getting out of hand. Probably not idiomatic but, I find it practical in these cases. if param.is_none() { // Handle, and continue, return an error etc } let value = param.as_ref().unwrap(); // or as_mut // Use `value` as normal.
You can rewrite it using let-or-else to get rid of the unwrap, which some would find to be more idiomatic. let value = Some(param.as_ref()) else { // Handle, and continue, return an error etc } // Use `value` as normal.
let Some(value) = param.as_ref() else {
// Handle, and continue, return an error etc
}
// Use `value` as normal.