CommunityNews

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

herbert

Author of Hands-on Rust

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

herbert

Author of Hands-on Rust

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

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());
}

Where Next?

Popular Backend topics Top

First poster: bot
For the first time in the history of TIOBE’s index, Java has slipped out of the top two, leaving Python to occupy the spot behind reignin...
New
First poster: OvermindDL1
This comes up in my conversations surprisingly often so I thought it’s worth to write my thoughts down instead of repeating them again an...
New
First poster: bot
In this episode, we look at some common functionality that we got with Rails UJS and what it looks like to reimplement these with Hotwire...
New
First poster: OvermindDL1
What we can learn from “_why” the long lost open source developer… Code might not last forever, but _why proves you can have an impact t...
New
CommunityNews
Multicore OCaml by kayceesrk · Pull Request #10831 · ocaml/ocaml. This PR adds support for shared-memory parallelism through domains and...
New
First poster: bot
TLDR; the future of ML is Julia. If you are looking for a quick answer, there you have it. If you want the well reasoned explanation, sti...
New
First poster: dimitarvp
Rails is not written in Ruby. I’m born and raised in Kraków, a beautiful city in Poland, maybe you’ve heard about it, maybe you’ve even ...
New
First poster: bot
GitHub - vitalik/django-ninja: :dash: Fast, Async-ready, Openapi, type hints based framework for building APIs. :dash: Fast, Async-rea...
New
CommunityNews
The History of Franz and Lisp. In 1984, while a graduate student in mathematics and in the relatively new Computer Science Department at...
New
First poster: bot
GitHub - nim-works/nimskull: An in development statically typed systems programming language; with sustainability at its core. We, the co...
New

Other popular topics Top

Devtalk
Reading something? Working on something? Planning something? Changing jobs even!? If you’re up for sharing, please let us know what you’...
1050 20964 393
New
New
PragmaticBookshelf
Brace yourself for a fun challenge: build a photorealistic 3D renderer from scratch! In just a couple of weeks, build a ray tracer that r...
New
AstonJ
Or looking forward to? :nerd_face:
487 12810 260
New
Rainer
My first contact with Erlang was about 2 years ago when I used RabbitMQ, which is written in Erlang, for my job. This made me curious and...
New
AstonJ
Do the test and post your score :nerd_face: :keyboard: If possible, please add info such as the keyboard you’re using, the layout (Qw...
New
New
New
PragmaticBookshelf
Develop, deploy, and debug BEAM applications using BEAMOps: a new paradigm that focuses on scalability, fault tolerance, and owning each ...
New
PragmaticBookshelf
Get the comprehensive, insider information you need for Rails 8 with the new edition of this award-winning classic. Sam Ruby @rubys ...
New