
CommunityNews
Why Rust should not have provided `unwrap`
Why Rust should not have provided
unwrap
.
I see the unwrap function called a lot, especially in example code, quick-and-dirty prototype code, and code written by beginner Rustaceans. Most of the time I see it, ? would be better and could be used instead with minimal hassle, and the remainder of the time, I would have used expect instead. In fact, I personally never use unwrap, and I even wish it hadn’t been included in the standard library.
Read in full here:
This thread was posted by one of our members via one of our news source trackers.
Most Liked

herbert
unwrap
is no different than not catching an exception in other languages. It’s handy for those times that you really can’t handle an error (for example, if you’re reading some text from stdin
in a simple program, you don’t want to try and recover from the OS deciding that console input isn’t available). It’s a conscious decision to crash if something exceptional happens.
I try to encourage people to use expect
, because it gives a nicer error message.
When you can recover from an error, there are some nicer options. unwrap_or(default)
, map
and similar can be nice, quick ways to handle “there isn’t a value here, or something didn’t work”.
The ?
operator is really useful, but only if you are writing a function that returns a Result
. You can make really nice function chains with do_this()?.do_that()?
chains - but it only makes sense if you are returning a result and doing something with it.

herbert
Hi! Thanks for the support!
That’s a really good question. To auto-flush or not is always a tricky design question (there’s literally decades of discussion in the C world on what to expect). I’d honestly prefer it if there were a flag you could set somewhere to change the behavior to flush after printing.
I’ve used the macro in this thread a couple of times to avoid having to think about it!
In the case of screen output, I think you can safely use unwrap()
. If stdout
has gone away, or become unavailable - you potentially have bigger problems to worry about. Unless you’re specifically writing something that needs to worry about it (e.g. you are writing something that needs to keep processing even though the output failed) - I’d keep it simple.

chikega
@herbert Hi Herbert, I’m a big fan of your books and a supporter on Patreon. Would you use .unwrap() or .expect() in the context of using the print! vs the
println! macro?
:
Some may not be aware, but using the print!
(w/o newline) vs println!
macro, it’s necessary many times to implement io::stdout().flush()
which will cause many beginner programmer’s eyes to glaze over. It’s probably the reason most introductory tutorials stick with the println!
macro in order not to overwhelm the beginner programmer. Example use case of printing without a newline:
use std::io;
use std::io::stdin;
use std::io::Write; // for .flush()
fn main() {
print!("What is your name? ");
io::stdout().flush().unwrap(); // or .expect("FAIL!");? here;
let mut fname = String::new();
stdin()
.read_line(&mut fname)
.expect("Failed to read line");
println!("It's nice to meet you {}!", fname.trim());
}
Popular General Dev topics









Other popular topics










Latest in General Dev
Latest (all)
Categories:
Popular Portals
- /elixir
- /rust
- /wasm
- /ruby
- /erlang
- /phoenix
- /keyboards
- /js
- /rails
- /python
- /security
- /go
- /swift
- /vim
- /clojure
- /java
- /haskell
- /emacs
- /svelte
- /onivim
- /typescript
- /crystal
- /c-plus-plus
- /tailwind
- /kotlin
- /gleam
- /react
- /flutter
- /elm
- /ocaml
- /vscode
- /opensuse
- /centos
- /ash
- /php
- /deepseek
- /zig
- /scala
- /html
- /debian
- /nixos
- /lisp
- /agda
- /textmate
- /sublime-text
- /react-native
- /kubuntu
- /arch-linux
- /revery
- /ubuntu
- /manjaro
- /spring
- /django
- /diversity
- /lua
- /nodejs
- /slackware
- /julia
- /c
- /neovim