7 ms·

I agree that in terms of safety it's equivalent. However in terms of how an actual program would be written it's...Less than optimal. I almost never simply allo

• Manishearth 10y ago
  Yeah, unwrap()s in examples should be written to use expect() (which spits a message and then panics). But for most example programs there's no easy way to handle errors further than just using expect() unless you want there to be more error handling code than actual useful example code.
  • pygy_ 10y ago
    Rust n00b here (I read a lot about it but haven't written a line yet), but wouldn't `.orPanic('error message')` be a better name than `.expect('error message')`? The latter seems backwards.
    • steveklabnik 10y ago
      It'd be or_panic, following conventions. The idea is that I expect this to be Ok/Some, and if it's not, please use this error message.
      • pygy_ 10y ago
        I understand the intent, but usually the programmatic object is the subject of the sentence, the method is the verb and the parameter/argument is the grammatical object. Here, the programmatic object is the grammatical object. That's what I meant by 'backwards'. could_fail().or_panic_with('message') may be even better.
        • steveklabnik 10y ago
          I don't neccesarily disagree. Names are hard :)
        • cgag 10y ago
          A lot of people don't seem to agree with me but I think even expect is too long of a name and terseness for commonly used names seems more important to me than reading like natural language.
          • Manishearth 10y ago
            You shouldn't really be using expect much :)
            • cgag 10y ago
              It's true I use and see unwrap more.
              • Manishearth 10y ago
                That's not good either :| unwrap should be confined to test and temporary code. It somewhat makes sense in example code, but expect is better for that. There are sometimes cases when you very easily know that the unwrap will never fail and if it does something has gone very horribly wrong, in which case you might use it. Libraries should keep usage of unwrap/expect to a minimum. Applications can be more liberal with it, but they should try to use expect or better error handling. Not everyone perfectly follows this, sadly. But most do.
                • pygy_ 10y ago
                  It's at least partly a matter of affordance. You could soft-deprecate .unwrap() and .expect() (emit warnings at compile time, it will be annoying but not fatal), and provide a new version of expect with a name that's more cumbersome to type (or_panic_with(...) isn't bad in that regard, but you could do even worse... or_panic_with_error_message(...) :-).
• steveklabnik 10y ago
  > even if it's just to spit out a log/stdout message. This will print an error out already. $ ./target/debug/tokiotest thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 98, message: "Address already in use" } }', ../src/libcore/result.rs:837 Printing out a _better_ error might be helpful, though, I'll agree :) You could use expect for that, which lets you change the message in the ''s easily. This really shows a fundamental tension though, in documentation. Is this example supposed to be demonstrating error handling? Or just get you going? Does adding more complex error handling distract from the point it's trying to teach? These are sort of open-ended questions.
  • Sharlin 10y ago
    The output of panic! seems to be useful only to the programmer, not the user. As a user, getting an error message like that would lead me to think that the application is defective, as it arguably is if it cannot provide better user experience in a completely expected error condition like a port being already in use.
    • steveklabnik 10y ago
      Absolutely. Your users aren't likely to be seeing a server-side process like this fail, though, so in this situation, seems fine. As I said in the post you're replying to, a nicer error message would be a good thing.
      • Sharlin 10y ago
        > Your users aren't likely to be seeing a server-side process like this fail, though, so in this situation, seems fine. Whoever maintains the server and runs the service is also my user, though, in the general case. > As I said in the post you're replying to, a nicer error message would be a good thing. Yeah - I don't mind if unwrap panics with a dev-oriented message as it's basically an assertion, but I guess I expected expect() (no pun intended) to give a more user-friendly error. Maybe the format of the panic! output could be changed to bring the message to the front and the technical details after that.
• hordeallergy 10y ago
  Agreed. Looking for examples of how to handle errors, results, etc and only ever finding unwrap has frustrated me in the past, and as a noob I would have preferred fleshed out rather than shortcuts.
  • steveklabnik 10y ago
    https://doc.rust-lang.org/stable/book/error-handling.html https://doc.rust-lang.org/stable/book/error-handling.html goes into fairly extreme level of details about this, if you're still trying to learn. http://rust-lang.github.io/book/ch12-03-improving-error-handling-and-modularity.html http://rust-lang.github.io/book/ch12-03-improving-error-hand... shows how to refactor a project to improve its error handling as well, for something a bit less abstract.
  • logingone 10y ago
    Sometimes a little context can be helpful.
• bryanlarsen 10y ago
  Doing anything other than a crash is often sub-optimal, in my experience. Such error handling code is usually untested, which is another way of saying 'buggy'. It almost always swallows useful information, like the backtrace. It sometimes lets program execution continue in a messed up state, causing very strange and hard to debug errors later on. Certainly Rust makes it a lot harder to mess up error handling code than the languages I'm used to but in general I'm definitely in the 'all exceptions fatal' camp.
  • nitrogen 10y ago
    An exception to the exception rule IMO is a program that is managing many internal tasks at once, and the failure of one should not bring down the others. For example, a program that is coordinating many IoT devices should not fail if one of those devices cannot be contacted.
    • notduncansmith 10y ago
      In the case of unreliable network peers, it isn't really "exceptional" that they be unreachable. It should just be represented as data.
• XorNot 10y ago
  This poses an interesting question: how hard is it in rust to enumerate all possible error sources from some code?