Using unwrap() in Rust is Okay (2022)

Summary

One day before Rust 1.0 was released, I published a blog post covering the fundamentals of error handling. A particularly important but small section buried in the middle of the article is named “unwrapping isn’t evil”. 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 generally still hold that belief today. That belief is put into practice in Rust’s standard library and in many core ecosystem crates. (And that practice predates my blog post.) Yet, there still seems to be widespread confusion about when it is and isn’t okay to use unwrap(). This post will talk about that in more detail and respond specifically to a number of positions I’ve seen expressed. This blog post is written somewhat as a FAQ, but it’s meant to be read in sequence. Each question builds on the one before it. Target audience: Primarily Rust programmers, but I’ve hopefully provided enough context that the principles espoused here apply to any programmer. Although it may be tricky to apply an obvious mapping to languages with different error handling mechanisms, such as exceptions. Table of Contents What is my position? I think it’s useful to state up front a number of my positions on error handling and panicking. This way, readers know exactly where I’m coming from. Panicking should not be used for error handling in either applications or libraries. It is possibly acceptable to use panicking for error handling while prototyping, in tests, benchmarks and documentation examples. If a Rust program panics, then it signals a bug in the program. That is, correct Rust programs don’t panic. There is always a way to assign “blame” as to the fault of the panic. It’s either the fault of the function that panicked, or the fault of the caller of that function. Outside of domains that need to use formal methods (or similar) to prove the correctness of their programs, it is impossible or impractical to move every invar...