Panicking when an Option is unwrapped should give a useful error message

[jimmycuadra]

Given the Rust program:

fn main() {
    let option: Option<bool> = None;
    option.unwrap();
}

Running the program outputs:

thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:365

The same program using expect instead of unwrap outputs:

thread '<main>' panicked at 'oops', ../src/libcore/option.rs:333

In a program of non-trivial size, figuring out which call to unwrap or expect generated the panic is harder than it needs to be, since the line shown is where the panic actually happens inside libcore. For improved ergonomics, the file and line reported should be from the user's source code where the unwrap or expect was called.

[frewsxcv]

How should the compiler know which stack frame to display in the error message when a panic happens?

[sfackler]

I am also unsure through what mechanism this would be implemented. Even stack crawling's going to fail without debug info and give bad results if functions have been inlined.

[oli-obk]

you can create a macro that reports the proper error file and line: http://is.gd/qhd6dt

this can probably be generalized by creating an Unwrappable trait and implementing it for Option and Result

[durka]

In case you don't know, setting RUST_BACKTRACE=1 in the environment will print a full stack trace on panics. Otherwise, yeah, this is why expect is preferred to unwrap.

[jimmycuadra]

I know about RUST_BACKTRACE. My concern here is about the ergonomics of dealing with errors for Rust developers—especially newcomers. Having to change unwraps to expects (which are often in upstream code and not modified as trivially) or to figure out the right arcane incantation of cargo or rustc to get output that is useful enough to proceed seems like it could be improved.

Similar/related issues:

• mention rust_panic in default panic! message #11704
• Make fail message more presentable #15239
• Change default output of panic! #30402
• Filter stdlib out of stack traces cargo#1633
• RUST_BACKTRACE=1 should be on by default for cargo test cargo#1634 (discussion of unwrap a bit further down)
• https://internals.rust-lang.org/t/cargo-test-and-backtraces/2518

[dtolnay]

This is going to need an RFC. Fortunately there already is one in rust-lang/rfcs#2091, and it seems to have passed FCP! I don't think we need this issue anymore, we can follow up there.