Live data from Hacker News

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

corrode.dev

61–63 of 63 posts

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

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

If you’re doing something like Project Euler, writing error messages is a waste of time.

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

#62
post #48
post #35

Earlier quoted context omitted.

It is a massive problem. It's basically the worse thing about C and they decided to copy it. Easily 60-70% of all go code is about propagating errors to the caller directly.

Not C. C errors are different since they are simply numbers. And spoiler alert, every language propagates errors. Sometimes automatically via exception handling, somewhat simply by returning error values. rust does this too. Matter fact, even javascript might be creeping toward this model of explicit error propagation soon. Good, because it is easier to understand.

Easier to understand and even easier to get it wrong!
Post reply on HN