Why Rust should not have provided `unwrap`

General Developer Forum In The News
,
1

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.

2 Likes
2

Corresponding tweet for this thread:

Share link for this tweet.

2 Likes
3

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.

3 Likes
4

@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());
}
2 Likes
5

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.

3 Likes
6

Thank you for your advice and the link to the macro … good stuff! :rocket:

2 Likes
7

This example would be better as:

use std::io;  
use std::io::stdin;
use std::io::Write; // for .flush()  

pub fn main() -> Result<(), std::io::Error> {
    print!("What is your name? ");  
    io::stdout().flush()?;
    let mut fname = String::new();
    stdin().read_line(&mut fname)?;
    
    println!("It's nice to meet you {}!", fname.trim());
    Ok(())
}

Or something that you can add context to like anyhow or one of its forks or so.

But yeah, I with we could #![forbid(unwrap_method)] or so in our modules to prevent its usage, expect is better when you are truly sure that it should never fail.

2 Likes