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. 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?...

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.

> 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_...

While I don't fully understand rust (not that I've really attempted to program in it much), I do really like the Result<T, E> 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<T> with its nullable types, like int?, which can either be an int or null

Great article by a rust legend. Two points:

  - The let-else syntax (Relatively new), anecdotally, removes many of my cases for unwrap. (But this may not apply to how others use it)
  - Unwrap's fine if it makes the code easier-to-read and you know it won't panic for a reason the compiler doesn't know about.

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::<i32>().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.

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

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 constructor `new URI(String) throws URISyntaxException`. URISyntaxException is checked exception which must be handled at invocation site or propagated to the caller. But you might need to write code like `var uri = new URI("https://example.com/")` and any error handling code will only be to please the compiler, essentially wasted work. Java solved it using `public static URI create(String str)` which does not throw checked exceptions and you're supposed to choose either constructor or factory method, depending in the circumstances.

Using Rust analogy, may be it would be useful for Java to write something like `var uri = unchecked new URI("https://example.com/");`, so with minimal syntax overhead you would signal that checked exceptions are not supposed to occur here (and if they did occur, then some unchecked UnexpectedCheckedException would throw here). It's actually possible to implement method `static T unchecked(CheckedSupplier<T, E> supplier)`, though syntax would be ugly: `var uri = unchecked(() -> new URI("https://example.com/"))`.

I think that this is general issue for programming languages. There's only one way to validate input parameters and report error. But whether those input parameters are trusted or not - only the caller knows. So nothing wrong about using `unwrap()` to signify the fact, that caller already made sure that error does not happen. The only important nuance is that error must not be swallowed if it happened.

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.

unwrap() is fine for experimental and WIP code. But it's a code smell for production. I usually do a git grep for unwrap and go one of two ways:

1. convert to an expect() - even if a panic is fine, you at least owe the future reader an explanation.

2. Use "proper" result handling, usually let Some, .ok_or, or a match.

Unwrap is a nice ergonomic cheat code to get the program compiled and leave a little TODO for yourself. You just need the discipline to circle back and clean them up, just like any debugging tool.

Just 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.

    let mutex_guard= mutex.lock().expect("poisoned lock");

I only use unwrap in tests

    [lints.clippy]
    unwrap_used = "deny"

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.

I agree that unwrap looks ugly. Sometimes I wish Rust had a ! operator like Swift and TypeScript do. But then that would encourage bad practises in non-test code, so…

> but the rendered example looks a lot better:

For doctests it makes total sense, but for regular test no so much.

It's a general issue with typed languages. Types are either too fine-grained or too coarse. Some more sophisticated languages can infer a whole lot but static type checking is still confusing and slows down builds. I tend to not worry much about them anymore -- about C language level types (maybe a bit more) is helpful and important for performance, but beyond that (e.g. types get dynamically instanciated from templates by the compiler) returns are diminishing quickly for many tasks.

The biggest robustness gains often come from making the right architectural decisions. That also applies to error handling as you described.

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.