Clippy lint · Restriction · checked with Clippy 0.1.99

clippy::unwrap_used: Checks for .unwrap() or .unwrap_err() calls on Results and .unwrap() call on Options

What it meansChecks for .unwrap() or .unwrap_err() calls on Results and .unwrap() call on Options. It is in the restriction group and off by default.

Does it matter?

It is better to handle the None or Err case, or at least call .expect(_) with a more helpful message. Still, for a lot of quick-and-dirty code, unwrap is a good choice, which is why this lint is Allow by default. result.unwrap() will let the thread panic on Err values. Normally, you want to implement more sophisticated error handling, and propagate errors upwards with ? operator. Even if you want to panic on errors, not all Errors implement good messages on display. Therefore, it may be beneficial to look at the places where they may get displayed. Activate this lint to do just that.

Lints that forbid language features for specific codebases (no unwrap, no indexing...). Off by default; pick them one by one, never the whole group.

How to fix it

Clippy does not fix this one automatically. Change the code by hand:

Flagged

option.unwrap();
result.unwrap();

Write this instead

option.expect("more helpful message");
result.expect("more helpful message");

Turn it off, or on

It is off by default. To use it, set it to warn or deny:

Whole crate (Cargo.toml)

[lints.clippy]
unwrap_used = "warn"

In code

#![warn(clippy::unwrap_used)]

One run

cargo clippy -- -W clippy::unwrap-used

The [lints] table needs Rust 1.74 or newer. In a workspace, put it under [workspace.lints.clippy] and add [lints] workspace = true to each member.

Settings in clippy.toml

allow-unwrap-in-consts: Whether unwrap should be allowed in code always evaluated at compile time
allow-unwrap-in-tests: Whether unwrap should be allowed in test functions or #[cfg(test)]
allow-unwrap-types: List of types to allow unwrap() and expect() on.

Restrictiongroup

allowdefault level

nofixed by cargo clippy --fix

1.45.0added in Rust

Clippy's own documentation

What it does

Checks for .unwrap() or .unwrap_err() calls on Results and .unwrap() call on Options.

Why restrict this?

It is better to handle the None or Err case, or at least call .expect(_) with a more helpful message. Still, for a lot of quick-and-dirty code, unwrap is a good choice, which is why this lint is Allow by default.

result.unwrap() will let the thread panic on Err values. Normally, you want to implement more sophisticated error handling, and propagate errors upwards with ? operator.

Even if you want to panic on errors, not all Errors implement good messages on display. Therefore, it may be beneficial to look at the places where they may get displayed. Activate this lint to do just that.

Examples

option.unwrap();
result.unwrap();

Use instead:

option.expect("more helpful message");
result.expect("more helpful message");

If expect_used is enabled, instead:

option?;

// or

result?;

Past names

option_unwrap_used
result_unwrap_used

Configuration

allow-unwrap-in-consts: Whether unwrap should be allowed in code always evaluated at compile time

(default: true)
allow-unwrap-in-tests: Whether unwrap should be allowed in test functions or #[cfg(test)]

(default: false)
allow-unwrap-types: List of types to allow unwrap() and expect() on.

Example

allow-unwrap-types = [ "std::sync::LockResult" ]

(default: [])

From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.

Up next

Also worth your time

Did this answer your question?