[vmg12]

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<RefCell<>> and Arc<Mutex> and feel free to unwrap everything, nobody will punish you.

[p1necone]

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

[Arnavion]

Or let-else with a panic!() in the else {} if you want to use a format string.

[xigoi]

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

[0cf8612b2e1e]

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

[Hackbraten]

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

[0cf8612b2e1e]

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

[vmg12]

Goto is bad because it results in very difficult to reason about code. Using unwrap and expect is as bad as using any other language without null safety.

[int_19h]

goto is bad when it's used in a way that makes it difficult to reason about code, but not all uses of goto are like that. The usual C pattern of `if (err) goto cleanup_resources_and_return_err;` is a good example of the use of goto that is not difficult to reason about.

Using unwrap/expect is still much better than using a language without null safety because unwrap/expect make it immediately obvious at which point a panic can occur, and creates some friction for the dev writing the code that makes them less likely to use it literally everywhere.

[iyn]

https://xkcd.com/87/ this one?