3 ms·

That reads as "I expect this to be already validated". Is that what you intended it to mean? Similarly, foo.expect("There was a problem and I had to crash")

That reads as "I expect this to be already validated". Is that what you intended it to mean? Similarly, foo.expect("There was a problem and I had to crash") That _reads_ as "I expect there to be a problem and have to crash". But it _means_ something totally different. It means: There should not be a problem, but if there were a problem I would crash and print out this message. And the way to write that in readable code is foo.unwrap_or_else(|| panic!("There was a problem and I had to crash")) I'm sorry if I'm misunderstanding -- if I am can you explain to me how? Because I feel like my view is diametrically opposed to yours but it's really not that subjective a matter; only one of us can be right.

iudqnolq 5y ago
You just phrase things the opposite way. I don't think it's clearly better to say the expected happy path or the unexpected sad path in a crash message. > That reads as "I expect this to be already validated". Is that what you intended it to mean? Yes > foo.expect("There was a problem and I had to crash") > That _reads_ as "I expect there to be a problem and have to crash". But it _means_ something totally different. It means: Absolutely. That's why I'd phrase it foo.expect("foo invariant upheld")
- da39a3ee 5y ago
  OK, that would be nice but...what you're saying just doesn't work! The user gets an error message saying thread 'main' panicked at 'foo invariant upheld' And everyone, except those who are inured to the illogic via experience, will read that as thread 'main' panicked because 'foo invariant upheld' especially new users, less experienced programmers, and non-Rust programmers seeing the panic message. Now if the Rust language made that error message say thread 'main' panicked at failed expectation for 'foo invariant upheld' that might be cool. But it does not do that. It feels like you're bending over backwards trying to excuse what is clearly a wart in a beautiful language. I'm happy to continue the debate though, I am fascinated to know how I can be wrong here :) So that's my main point, that your strategy doesn't work due to the error message. But a secondary point is that Rust documentation encourages people to use it opposite to what you suggest: I mean, just look at the first example in the Rust book. It's completely nonsensical: let f = File::open("hello.txt").expect("Failed to open hello.txt"); I know there was some controversy about this early on and somehow it didn't get reverted; it would be more honest if the docs would at least admit that it's "a little strange". https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html?highlight=expect#shortcuts-for-panic-on-error-unwrap-and-expect https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi... Playground if you want to remind yourself of the psychological experience of seeing that error message at run time with minimal effort. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=39c752f25bcdb10f05f244fae76c545f https://play.rust-lang.org/?version=stable&mode=debug&editio...
  - iudqnolq 5y ago
    Outside of tests and toy examples you're generally expected to only panic when the developer has failed to uphold an invariant, not when the user has. As a result there's generally nothing a non-rust-developer can do with the message besides post it on the bug tracker.
    - da39a3ee 5y ago
      Right, so that's relevant to a minor incidental comment I made. But what do you think of the main points, which are (a) If you write the message the way you suggest the printed error message is misleading, and (b) The Rust community does not encourage using .expect() in the way you suggest; in particular the canonical Rust documentation source instructs us to use it as foo.expect("A thing I do not expect")
      - da39a3ee 5y ago
        Similarly, from the rust stdlib docs for process::Command let hello_1 = echo_hello.output().expect("failed to execute process");

iudqnolq 5y ago

You just phrase things the opposite way. I don't think it's clearly better to say the expected happy path or the unexpected sad path in a crash message. > That reads as "I expect this to be already validated". Is that what you intended it to mean? Yes > foo.expect("There was a problem and I had to crash") > That _reads_ as "I expect there to be a problem and have to crash". But it _means_ something totally different. It means: Absolutely. That's why I'd phrase it foo.expect("foo invariant upheld")

da39a3ee 5y ago
OK, that would be nice but...what you're saying just doesn't work! The user gets an error message saying thread 'main' panicked at 'foo invariant upheld' And everyone, except those who are inured to the illogic via experience, will read that as thread 'main' panicked because 'foo invariant upheld' especially new users, less experienced programmers, and non-Rust programmers seeing the panic message. Now if the Rust language made that error message say thread 'main' panicked at failed expectation for 'foo invariant upheld' that might be cool. But it does not do that. It feels like you're bending over backwards trying to excuse what is clearly a wart in a beautiful language. I'm happy to continue the debate though, I am fascinated to know how I can be wrong here :) So that's my main point, that your strategy doesn't work due to the error message. But a secondary point is that Rust documentation encourages people to use it opposite to what you suggest: I mean, just look at the first example in the Rust book. It's completely nonsensical: let f = File::open("hello.txt").expect("Failed to open hello.txt"); I know there was some controversy about this early on and somehow it didn't get reverted; it would be more honest if the docs would at least admit that it's "a little strange". https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html?highlight=expect#shortcuts-for-panic-on-error-unwrap-and-expect https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi... Playground if you want to remind yourself of the psychological experience of seeing that error message at run time with minimal effort. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=39c752f25bcdb10f05f244fae76c545f https://play.rust-lang.org/?version=stable&mode=debug&editio...
- iudqnolq 5y ago
  Outside of tests and toy examples you're generally expected to only panic when the developer has failed to uphold an invariant, not when the user has. As a result there's generally nothing a non-rust-developer can do with the message besides post it on the bug tracker.
  - da39a3ee 5y ago
    Right, so that's relevant to a minor incidental comment I made. But what do you think of the main points, which are (a) If you write the message the way you suggest the printed error message is misleading, and (b) The Rust community does not encourage using .expect() in the way you suggest; in particular the canonical Rust documentation source instructs us to use it as foo.expect("A thing I do not expect")
    - da39a3ee 5y ago
      Similarly, from the rust stdlib docs for process::Command let hello_1 = echo_hello.output().expect("failed to execute process");