Using unwrap() in Rust is Okay (2022)
burntsushi.net
Using unwrap() in Rust is Okay (2022)
1–10 of 54 posts
Re: Using unwrap() in Rust is Okay (2022)
#2Just don’t put unwrap in library code, please. Not if it can possibly happen, bearing in mind that you can make mistakes.
I like my background threads to be infallible. If they panic, then chances are nothing will notice and the rest of the program will solely seize up.
I might have agreed with more of this article if panics actually crashed the program, but in multithreaded Rust that’s rarely the case.
Re: Using unwrap() in Rust is Okay (2022)
#3> That section briefly described that, broadly speaking, using unwrap() is okay if it’s in test/example code or when panicking indicates a bug.
I've come to the conclusion that even in tests unwraps look ugly. Especially in doc tests which serve as examples the code is better off using regular "?" that one would see in other parts of code. (that is: don't treat test code as a "worse" kind of code)
In Signstar we're using testresult which still panics under the hood (which is OK for tests) https://gitlab.archlinux.org/archlinux/signstar/-/blob/main/... but the rendered example looks a lot better: https://docs.rs/nethsm/latest/nethsm/enum.OpenPgpVersion.htm...
Note that I'm currently maintaining that crate but the design is described at https://www.bluxte.net/musings/2023/01/08/improving_failure_...
Re: Using unwrap() in Rust is Okay (2022)
#4While I don't fully understand rust (not that I've really attempted to program in it much), I do really like the Result convention. Before I knew about it, I used a similar construct in a couple of places in my C# code, but I think I'll make my own version of it and try to use it more often. I don't think C# has a builtin version anyway, I know it has a builtin that does the same as Option with its nullable types, like int?, which can either be an int or null
Re: Using unwrap() in Rust is Okay (2022)
#5> That section briefly described that, broadly speaking, using unwrap() is okay if it’s in test/example code or when panicking indicates a bug. I've come to the conclusion that even in tests unwraps look ugly. Especially in doc tests which serve as examples the code is better off using regular "?" that one would see in other parts of code. (that is: don't treat test code as a "worse" kind of code) In Signstar we're u…
I always felt unwrap is preferable for diagnosing issues, which makes it useful in tests. A failed unwrap will point you directly to the line of code which panics, which is much simpler than trying to trace an issue through many layers of Results.
If you use `assert` in tests, I don't understand why you wouldn't also prefer unwrap in this context.
I think it's also perfectly reasonable to use in a context like binary you run locally for private consumption, or for instance a serverless function which allows you to pinpoint the source of errors more easily in the logs.
It's not a good fit for cases where you do expect cases where the unwrap will fail, but it's a great fit for cases where you believe the unwrap should always succeed, as it allows you to pinpoint the cases where it fails.
Re: Using unwrap() in Rust is Okay (2022)
#6I do not think a code full of unwrap() (which I have seen often) is a nice thing to look at.
Re: Using unwrap() in Rust is Okay (2022)
#7I only use unwrap in tests
Re: Using unwrap() in Rust is Okay (2022)
#8The 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. Panicking is always fatal in Zig. The nice thing about this is that you cannot use panics for exception-style control flow, which removes any temptation to use them for user errors.
[0] https://ziggit.dev/t/i-wrote-a-simple-sudoku-solver/9924/12?...
Re: Using unwrap() in Rust is Okay (2022)
#9Just don’t put unwrap in library code, please. Not if it can possibly happen, bearing in mind that you can make mistakes. I like my background threads to be infallible. If they panic, then chances are nothing will notice and the rest of the program will solely seize up. I might have agreed with more of this article if panics actually crashed the program, but in multithreaded Rust that’s rarely the case.
> I might have agreed with more of this article if panics actually crashed the program, but in multithreaded Rust that’s rarely the case.
Why is that?
Re: Using unwrap() in Rust is Okay (2022)
#10The 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 .…
> which removes any temptation to use them for user errors.
It doesn't look to be too much of a temptation to use panics as regular errors in Rust though, so I don't think it gains you much.
And it makes it more complicated when you want to catch panics for legitimate reasons (like when you want to show an error box to the user, instead of silently crashing, or when you want to send the crash log for later analysis). It's still possible, by using a separate process, but it's unnecessary friction in order to prevent a sin that doesn't happen in practice.