Rust

5974 readers

98 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago

MODERATORS

[email protected]

Dioxus Labs + “High-level Rust (dioxus.notion.site)

submitted 4 months ago by [email protected] to c/[email protected]

19 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] -1 points 4 months ago (2 children)

Fair. But unwrap versus expect isn't really the point. Sure one has a better error message printed to your backtrace. But IMO that's not what I'm looking for when I'm looking at a backtrace. I don't mind plain unwraps or assertions without messages.

From my experience, when people say "don't unwrap in production code" they really mean "don't call panic! in production code." And that's a bad take.

Annotating unreachable branches with a panic is the right thing to do; mucking up your interfaces to propagate errors that can't actually happen is the wrong thing to do.

[–] [email protected] 3 points 4 months ago

that’s not what I’m looking for when I’m looking at a backtrace. I don’t mind plain unwraps or assertions without messages.

You're assuming the PoV of a developer in an at least partially controlled environment.

Don't underestimate the power of (preferably specific/unique) text. Text a user (who is more likely to be experiencing a partially broken environment) can put in a search engine after copying it or memorizing it. The backtrace itself at this point is maybe gone because the user didn't care, or couldn't copy it anyway.

[–] [email protected] 0 points 4 months ago (1 children)

From my experience, when people say “don’t unwrap in production code” they really mean “don’t call panic! in production code.” And that’s a bad take.

What should be a non-absolutest mantra can be bad if applied absolutely. Yes.

Annotating unreachable branches with a panic is the right thing to do; mucking up your interfaces to propagate errors that can’t actually happen is the wrong thing to do.

What should be a non-absolutest mantra can be bad if applied absolutely.

[–] [email protected] 1 points 4 months ago (1 children)

You talk about "non-absolutist," but this thread got started because the parent comment said "literally never."

I am literally making the point that the absolutist take is bad, and that there are good reasons to call unwrap in prod code.

smdh

[–] [email protected] -1 points 4 months ago (1 children)

Don't get angry with me my friend. We are more in agreement than not re panics (not .unwrap(), another comment coming).

Maybe I'm wrong, but I understood 'literally' in 'literally never' in the way young people use it, which doesn't really mean 'literally', and is just used to convey exaggeration.

[–] [email protected] 2 points 4 months ago

No, I actually meant it as in the traditional meaning of literally. As in

[lints.clippy]
unwrap_used = "warn"
expect_used = "warn"

along with a pre-commit hook that does

cargo clippy -D warnings

(deny warnings).

There are always better ways to write an unwrap, usually via pattern matching and handling the error cases properly, at the very least logging them.