thread '<main>' panicked at 'called Result::unwrap() on an Err value: Error { repr: Os(1455) }'

[jeroldhaas]

Error:

thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os(1455) }'

Code found (& system-torture enhanced) from online Rust book Ch 3.3 (embed project example).

I'd modified the thread count from original 11 threads to 10,000,001 threads to see how / if a thread limit would be reached. I'm assuming this may be the initial cause for the panic, however Os(1455) doesn't really describe an Error's repr very well.

_As I'm not completely familiar with Rust, I was advised to submit this as an issue by someone more familiar with the language._

See (modified) code example below for repro:

use std::thread;

fn main() {
   let handles: Vec<_> = (0..10_000_000).map(|_| {
       thread::spawn(|| {
           let mut _x = 0;
           for _ in (0..5_000_001) {
               _x += 1
           }
       })
    }).collect();

    for h in handles {
       h.join().ok().expect("Could not join a thread");
    }
}

Platform:

• Rust 1.0 Stable 64bit Windows Build
• Windows 8 x64

[steveklabnik]

Hey @jeroldhaas , thanks for the report.

What specifically is the action to take here? Is it about a better error message, or explaining what's going on?

[jeroldhaas]

@steveklabnik : Ultimately, a more informative error message would be best. A user unfamiliar with the language (such as myself) may encounter an error such as this and be left to divination techniques to try and decipher what the issue was at that moment in the thread where it panicked.

That said, there may be an issue with thread management here, but deciphering the panic message seems quite impenetrably opaque with the message currently given, so... Now what?

AFAIK (as a beginner), using thread::spawn().collect() isn't considered an unsafe operation, so I don't understand why unwrap() is being called on Error anyway. Perhaps this is why I was told to submit the issue?

[steveklabnik]

So there's always a tension between these kinds of things in examples: super robust error handling gets in the way of what the example is trying to convey.

In this case, the default message for errors just shows the very basics. In this case, that we got an OS-specific error code, and that that code was 1455.

AFAIK (as a beginner), using thread::spawn().collect() isn't considered an unsafe operation, so I don't understand why unwrap() is being called on Error anyway

unwrap() isn't about safety, exactly. You didn't indicate where the error was thrown, I can explain more about that, depending. I don't have a Windows machine handy to test.

[jeroldhaas]

I understand. I'd be happy to re-run this tonight and give you the full cargo run -v output this evening.

As for Os(1455), would a look-up table based on current executing platform be of any assistance? Being given an error code without an accompanying string doesn't help a developer with their dilemma. 😃

[Stebalien]

Given the platform, you can always lookup the error (https://msdn.microsoft.com/en-us/library/windows/desktop/ms681385(v=vs.85).aspx#ERROR_COMMITMENT_LIMIT).

Unwrap is being called on a Result. Result::unwrap used to use the Display trait (implemented on the error type) to format error messages but switched to the Debug trait to avoid forcing all errors to implement Display.

[jeroldhaas]

@Stebalien my point was that if there was an API to look up these codes to return their accompanying user-friendly strings from the system, or a collection of a sort in an error codes package with info for each platform, the developer/user wouldn't have to go searching for what these esoteric error numbers might be.

[retep998]

It would be really nice if Debug for Error would do the same error message lookup that Display does instead of just printing out the error code.

[steveklabnik]

I'm changing this to libs, because it's not clear to me how to change these docs. We may or may not want to change the representation of Debug here, or what documentation needs changed. What do you think, @rust-lang/libs ?

[sfackler]

This came up in the Result::expect RFC as well: rust-lang/rfcs#1119 (comment). We may want to update the Debug impl in the short term, but specializing unwrap and expect when E: Display might be a better long term solution when specialization is added.

[steveklabnik]

Triage: no changes I'm aware of

[retep998]

Was fixed by me: #26416