Live data from Hacker News

Don't unwrap options: There are better ways (2024)

corrode.dev

11–20 of 63 posts

Re: Don't unwrap options: There are better ways (2024)

#11
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.

Re: Don't unwrap options: There are better ways (2024)

#12
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 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)

#13
post #12

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…

Plus it gives others the opportunity to post that xkcd velociraptor strip.

Re: Don't unwrap options: There are better ways (2024)

#14

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?

Re: Don't unwrap options: There are better ways (2024)

#15

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.

Re: Don't unwrap options: There are better ways (2024)

#16
post #5

I 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

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.

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?

Indeed, and it even suggests the 2nd solution. All you have to do is read from the top, not the bottom, of the error message

Re: Don't unwrap options: There are better ways (2024)

#18
post #5

I 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; }

gleam:

    fn get_user_name() -> Result(String, String) {
        use user 

Re: Don't unwrap options: There are better ways (2024)

#19
post #9

Talking 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?

It was the first time I set it up, then I went through every single instance and refactored with the appropriate choice. It wasn't as tedious as you might imagine, and again, I really don't have the option of letting my game crash.

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)

#20
post #12

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…

Plus it gives others the opportunity to post that xkcd velociraptor strip.

https://xkcd.com/87/ this one?
Post reply on HN