if param.is_none() {
// Handle, and continue, return an error etc
}
let value = param.as_ref().unwrap(); // or as_mut
// Use `value` as normal.Don't unwrap options: There are better ways (2024)
11–20 of 63 posts
Re: Don't unwrap options: There are better ways (2024)
#12Also, 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 very strict language. You still get a ton of the benefits of Rust when writing non-idiomatic Rust. Just use the Rc> and Arc and feel free to unwrap everything, nobody will punish you.
Re: Don't unwrap options: There are better ways (2024)
#13Also, 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…
Re: Don't unwrap options: There are better ways (2024)
#14Something 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.
Re: Don't unwrap options: There are better ways (2024)
#15Something 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.
let value = Some(param.as_ref()) else {
// Handle, and continue, return an error etc
}
// Use `value` as normal.Re: Don't unwrap options: There are better ways (2024)
#16I have been using Zig a lot lately, and I just want to share the equivalent of the let-else solution in Zig: const user = getUser() orelse return error.NoUser; If you only need user for a narrow scope like you would get from match, you can also use if to unwrap the optional. if (getUser()) |user| { // use user } else { return error.NoUser; }
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
Re: Don't unwrap options: There are better ways (2024)
#17> My main gripe with this error message is that it doesn’t explain why the ? operator doesn’t work with Option in that case… just that it doesn’t. The error in question: > the `?` operator can only be used on `Result`s, not `Option`s, in a function that returns `Result` It literally tells you why it doesn't work, wtf do you want?
Re: Don't unwrap options: There are better ways (2024)
#18I have been using Zig a lot lately, and I just want to share the equivalent of the let-else solution in Zig: const user = getUser() orelse return error.NoUser; If you only need user for a narrow scope like you would get from match, you can also use if to unwrap the optional. if (getUser()) |user| { // use user } else { return error.NoUser; }
fn get_user_name() -> Result(String, String) {
use user Re: Don't unwrap options: There are better ways (2024)
#19Talking about unwrapping: I’ve been using a rather aggressive list of clippy lints to prevent myself from getting panics, which are particularly deadly in real-time applications (like video games). unwrap/expect_used already got me 90% of the way out, but looking at the number of as conversions in my codebase, I think I have around 300+ numerical conversions (which can and do fail!) [lints.clippy] all = "deny" unwrap…
Does that mean your code is annotated with 300+ instances of `#[allow(clippy::unwrap_used)]` et al?
I think the only legitimate uses are for direct indexing for tile maps etc. where I do bounds checking on two axes and know that it will map correctly. to the underlying memory (but that's `clippy::indexing_slicing`, I have 0 `clippy::unwrap_used` in my codebase now).
If you begin a new project with these lints, you'll quickly train to write idiomatic Option/Result handling code by default.
Re: Don't unwrap options: There are better ways (2024)
#20Also, 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…
Plus it gives others the opportunity to post that xkcd velociraptor strip.