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

Using unwrap() in Rust is Okay (2022)

burntsushi.net

Post reply on HN
Print view View original

31–40 of 54 posts

Re: Using unwrap() in Rust is Okay (2022)

#31

Post by Galanwe »

Zambyte wrote: post #8

The article pretty much says this as well, but a concise way I saw Andrew Kelley put it recently in the context of Zig (but it seems to apply well for any language that has errors-as-values + panics) is: "Assertions for programmer mistakes; errors for user mistakes."[0] One interesting difference between Zig and other languages with similar error stories (Rust, Go) is that panicking can be handled but not recovered .…

From my experience, Zig is the worst at error handling.

Not that the language itself make it hard, on the contrary, but the standard library itself is littered with opinionated error handling that straight up panic with no recovery at every corner.

For instance, it was decided that the kernel returning EINVAL for any syscall is worth panicking, even though there are a lot of cases where that is recoverable. The answer from Andrew? It's the kernel's fault. Very helpful.

Quotes are cute, but their actual implementation matters more.

Re: Using unwrap() in Rust is Okay (2022)

#32

Post by im3w1l »

vbezhenar wrote: post #19

The general issue, as I see it: One function is too general and handles all inputs. Some inputs are wrong and code returns error. Some languages forces you to handle that error. Another code snippet uses that function with very specific inputs which must not cause errors, but was forced to handle error, because of language rules. This error handling is essentially useless. I saw this issue with Java. There's construc…

I think the "correct" way to do it at a language level is for the compiler to construct the URI at compile time when possible. The successful construction proves that it cannot throw exceptions and hence they don't need to be handled.

Re: Using unwrap() in Rust is Okay (2022)

#33

Post by gwbas1c »

My biggest beef with "unwrap" is that it doesn't contain an error message. Because I generally follow the mantra that panics are for unrecoverable errors, (typically bugs,) some kind of error message is critical in debugging the situation. (Because no program should fail with "mystery error".)

I went back to https://doc.rust-lang.org/core/option/enum.Option.html and I can't seem to find an alternative to "unwrap" that includes an error message. I vaguely remember finding an alternative to unwrap with an error message, but because I don't use Rust on a daily basis, I can't seem to remember how I did it.

Re: Using unwrap() in Rust is Okay (2022)

#34

Post by 0l »

gwbas1c wrote: post #33

My biggest beef with "unwrap" is that it doesn't contain an error message. Because I generally follow the mantra that panics are for unrecoverable errors, (typically bugs,) some kind of error message is critical in debugging the situation. (Because no program should fail with "mystery error".) I went back to https://doc.rust-lang.org/core/option/enum.Option.html and I can't seem to find an alternative to "unwrap" tha…

Perhaps expect() would work?

Re: Using unwrap() in Rust is Okay (2022)

#35

Post by ChristianJacobs »

gwbas1c wrote: post #33

My biggest beef with "unwrap" is that it doesn't contain an error message. Because I generally follow the mantra that panics are for unrecoverable errors, (typically bugs,) some kind of error message is critical in debugging the situation. (Because no program should fail with "mystery error".) I went back to https://doc.rust-lang.org/core/option/enum.Option.html and I can't seem to find an alternative to "unwrap" tha…

You're looking for `.expect()`, available on both Option and Result.

Re: Using unwrap() in Rust is Okay (2022)

#36

Post by davidjfelix »

Unwrap is fine if used sparingly and as mentioned, to indicate a bug, but in practice it requires discipline and some wisdom to use properly - and by that I mean not just "oh this function should be a `Result` but I'll add that later (never).

I think relying on discipline alone in a team is usually a recipe for disaster or at the very least resentment while the most disciplined must continually educate and correct the least disciplined or perhaps least skilled. We have a clippy `deny` rule preventing panics, excepts, and unwraps, even though it's something we know to sometimes be acceptable. We don't warn because warnings are ignored. We don't allow because that makes it too easy to use. We don't use `forbid`, a `deny` that can't be overridden, because there are still places it could be helpful. What this means is that the least disciplined are pushed to correct a mistake by using `Result` and create meaningful error handling. In cases where that does not work, extra effort can be used to add an inline clippy allow instruction. We strongly question all inline clippy overrides to try to avoid our discipline collapsing into accepting always using `unwrap` & `allow` at review time to ensure nothing slips by mistakenly. I will concede that reviews themselves are potentially a dangerous "discipline trap" as well, but it's the secondary line of defense for this specific mistake.

Re: Using unwrap() in Rust is Okay (2022)

#37

Post by goku12 »

johnisgood wrote: post #6

I do not think a code full of unwrap() (which I have seen often) is a nice thing to look at.

That's not what the article is saying, despite what the title implies. He is saying that while unwrap should be generally avoided, there are a few genuine use cases for it.

I follow his advise on error handling, since that's what I found convenient as well. Rust error handling is hard to get started with. But you need to learn it only once before it becomes a second nature. Most of my projects contain only a handful of unwraps.

Re: Using unwrap() in Rust is Okay (2022)

#38

Post by johnisgood »

Galanwe wrote: post #31
Zambyte wrote: post #8

The article pretty much says this as well, but a concise way I saw Andrew Kelley put it recently in the context of Zig (but it seems to apply well for any language that has errors-as-values + panics) is: "Assertions for programmer mistakes; errors for user mistakes."[0] One interesting difference between Zig and other languages with similar error stories (Rust, Go) is that panicking can be handled but not recovered .…

From my experience, Zig is the worst at error handling. Not that the language itself make it hard, on the contrary, but the standard library itself is littered with opinionated error handling that straight up panic with no recovery at every corner. For instance, it was decided that the kernel returning EINVAL for any syscall is worth panicking, even though there are a lot of cases where that is recoverable. The answe…

My problem with panics is that if it is a library (e.g. standard library), then I cannot handle the error the way I want. Let us say that you have a library that parses something. As the user of that library, you want to be able to handle these errors gracefully, you do not want the library to just panic at those parse errors. Sadly I have seen libraries do this.

Re: Using unwrap() in Rust is Okay (2022)

#39

Post by axegon_ »

I saw that article in 2023 and I have mixed feelings. In general there are cases where you want a program to crash and it's a preferable option as opposed to a never-ending chain of handling. For that purpose, unwrap is actually perfect. It is also great for examples, documentation, so that people can see what to expect and how a certain block should behave.

But there's the other case(which I've also suffered from). It is tempting to do the fast thing when you are on a tight schedule. One such instance was when we had to deliver something which was arguably undeliverable within the deadline we had. There were two services which were communicating over gRPC, and to make matters worse, not tonic but some custom implementation. But those worked surprisingly well against all odds. But there was a third service where we had to use a regular, plain ol' boring http requests. "I'm returning you the ID as a string inside the response, just cast it to a 32 bit integer and you're good to go" they said. "Fair", I thought: response_id::().unwrap(), compile and deploy. Needless to say, the ID was not a 32 bit integer. Point is, if you control the entire ecosystem you are working on, unwrap, although undesirable in many cases, is fine. Anything else - handle the errors.

Re: Using unwrap() in Rust is Okay (2022)

#40

Post by epcoa »

axegon_ wrote: post #39

I saw that article in 2023 and I have mixed feelings. In general there are cases where you want a program to crash and it's a preferable option as opposed to a never-ending chain of handling. For that purpose, unwrap is actually perfect. It is also great for examples, documentation, so that people can see what to expect and how a certain block should behave. But there's the other case(which I've also suffered from).…

> It is tempting to do the fast thing when you are on a tight schedule.

The alternative option in C or C++ is to do some undefined behavior. Before a pile on, yes of course you can avoid it but the rush option is usually going to be the equivalent of unwrap anyway, and Rust does make it quite a bit harder to invoke undefined behavior.

Post reply on HN