Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

corrode.dev

Post reply on HN
Print view View original

21–30 of 63 posts

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

#21

Post by jimbokun »

aatd86 wrote: post #16
robertlagrant wrote: post #10

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.

The problem is the compiler doesn’t help you if you forget to check err.

Although it will flag unused variable. So you will have to make an effort to deliberately ignore the error value.

Still not quite as nice as the compiler forcing you to handle the error case.

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

#22

Post by p1necone »

evrimoztamur wrote: post #6

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…

yoink (although I will probably allow expect - having to provide a specific message means I'm only going to use it in cases where there's some reasonable justification)

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

#23

Post by Hackbraten »

0cf8612b2e1e wrote: post #13
vmg12 wrote: 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.

Do you mean this one? https://xkcd.com/292/

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

#25

Post by 0cf8612b2e1e »

Hackbraten wrote: post #23
0cf8612b2e1e wrote: post #13

Earlier quoted context omitted.

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

Do you mean this one? https://xkcd.com/292/

Yes, exactly. It is the Rust equivalent of goto.

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

#26

Post by p1necone »

vmg12 wrote: 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…

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.")

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

#28

Post by theon144 »

tengbretson wrote: post #24

I'm not very familiar with Rust. Do the built in Option and Result types not implement map and flatMap?

They do, `map` and `and_then`.

As for the article, I'm also a bit confused because I'm really not sure whether people write that sort of code at the beginning "very commonly" - match and `ok_or` to handle None by turning them into proper Errors is one of the first things you learn in Rust.

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

#29

Post by frizlab »

ChadNauseam wrote: post #2

let-else is awesome. definitely my favorite rust syntax. The compiler checks that the else branch will “diverge” (return, panic, break, or continue), so it’s impossible to mess it up. the article says “It’s part of the standard library,” which gets the point across that it doesn’t require any external dependencies but it may be slightly misleading to those who interpret it literally - let-else a language feature, not…

Swift has guard. Equally awesome.

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

#30

Post by fjasdfas »

robertlagrant wrote: post #10
Zambyte wrote: 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

`:=` was new to me: https://peps.python.org/pep-0572/

It actually looks really natural in python, glad they added.

Post reply on HN