3 ms·

I didnt say it was unsafe, I said it crashes. Unwrap is a shortcut to let you be lazy; it exists for no other reason, and it causes application level crashes i

I didnt say it was unsafe, I said it crashes. Unwrap is a shortcut to let you be lazy; it exists for no other reason, and it causes application level crashes in way that is very much easier to avoid in other languages. That 'catch_unwind' exists is evidence that some kind of panic recovery is necessary... and I wonder how often you hit it from a real panic, vs. a stray lazy unwrap? Whats your justification for unwrap? I've never seen a meaningful justification for it other than not wanting to handle errors properly. An application error (returned null) shouldn't abort your application with a hard error, no logs. Its just plain poor practice to use unwrap().

steveklabnik 9y ago
> I didnt say it was unsafe, I said it crashes. Your phrasing implied that you said the crash was not safe, as you put "unsafe" in quotes and contrasted it with the crash. At least, that's what I understood you to be saying too.
- shadowmint 9y ago
  meh. I feel like any time someone mentions the word 'safe' regardless of context, the rust safety pedants roll out of the woodwork to dispute to dispute any minute detail of what's been said, regardless of if its relevant to the discussion at hand. I shouldn't have put 'safe' in the comment at all, what a waste of a thread. My point had nothing to do with safety; it was purely that having given advice being to write good code that doesn't panic, and then having code that shamelessly panics in all your examples is hypocritical. `?` is a better choice in basically every case; I'm glad to see the documentation will be moving eventually towards using that.
  - jjnoakes 9y ago
    In the context of this article and discussion, panics via unwrap (or better, expect) is a fine answer, and I'm not sure why you think it is hypocritical to suggest it, especially to Rust newcomers who are looking to write script-like programs. Panics mostly match the verbosity, ergonomics, and functionality of the analogous python script. Now I agree that a caveat should follow advice like using unwrap and expect, perhaps a small blurb about how they should eschewed for better error handling when you want to catch the errors and make decisions because of them (especially when writing libraries) but that's quite a bit short of hypocritical to me.
    - shadowmint 9y ago
      > a caveat should follow advice like using unwrap and expect, perhaps a small blurb about how they should eschewed for better error handling when you want to catch the errors and make decisions because of them. That is literally the definition of hypocrisy; the behavior of people who do things that they tell other people not to do. "When you do this, do it like this, but properly with error handling." :P Anyhow, as I said its my oppinion that unwrap() is lazy, and `?`, `expect` and `assert!` cover the same functionality in more explicit and meaningful way. You're welcome to your own opinion.
      - jjnoakes 9y ago
        > That is literally the definition of hypocrisy; the behavior of people who do things that they tell other people not to do Except I'm not saying that at all. I said it's fine to use unwrap() or expect() if you want script-like default behavior (a developer-centric error message and a quick exit with a bad return code) and if you want something more than that, then use something better than unwrap() or expect(). There's no hypocrisy here. I think anyone should follow that advice. Me, you, a newb to Rust, a Rust veteran, anyone. Same advice.
jjnoakes 9y ago
> unwrap [...] causes application level crashes in way that is very much easier to avoid in other languages Unwrap does what just about every other language with exceptions-by-default does: it prints out a message for developers and exits. If you don't want that behavior, that's fine; in Rust you'd not use unwrap(), and in other languages you'd catch the exception. Now, I agree that if you are using a library which does unwrap() in Rust vs a library that throws an exception in Python, you have different situations. But unwrap() isn't meant to be used in libraries (or if it is, only for fatal errors which should be uncatchable). > Whats (sic) your justification for unwrap? I've never seen a meaningful justification for it other than not wanting to handle errors properly. That is the justification for it: you are writing a simple short script-like tool (or you are prototyping or exploring some problem through one-off or throw-away code) and you want any errors to immediately exit with a developer-centric message and failure code. unwrap() is perfect for this. It's the same justification for not catching every exception in other languages. Sometimes you are fine with an error printing a message and exiting.
MichaelGG 9y ago
>An application error (returned null) shouldn't abort your application with a hard error, no logs. Its just plain poor practice to use unwrap(). What? That's what every other language does. file.open("foo").read_line() If open fails it'll either throw or return null which will then cause read_line to throw a null pointer exception. Rust just makes things explicit here. Though it might be interesting if there was a special opt-in Deref impl for Result and Option so people could omit the unwrap and just get it implicitly, for the occasions when you don't want that explicitness.

steveklabnik 9y ago

> I didnt say it was unsafe, I said it crashes. Your phrasing implied that you said the crash was not safe, as you put "unsafe" in quotes and contrasted it with the crash. At least, that's what I understood you to be saying too.

shadowmint 9y ago
meh. I feel like any time someone mentions the word 'safe' regardless of context, the rust safety pedants roll out of the woodwork to dispute to dispute any minute detail of what's been said, regardless of if its relevant to the discussion at hand. I shouldn't have put 'safe' in the comment at all, what a waste of a thread. My point had nothing to do with safety; it was purely that having given advice being to write good code that doesn't panic, and then having code that shamelessly panics in all your examples is hypocritical. `?` is a better choice in basically every case; I'm glad to see the documentation will be moving eventually towards using that.
- jjnoakes 9y ago
  In the context of this article and discussion, panics via unwrap (or better, expect) is a fine answer, and I'm not sure why you think it is hypocritical to suggest it, especially to Rust newcomers who are looking to write script-like programs. Panics mostly match the verbosity, ergonomics, and functionality of the analogous python script. Now I agree that a caveat should follow advice like using unwrap and expect, perhaps a small blurb about how they should eschewed for better error handling when you want to catch the errors and make decisions because of them (especially when writing libraries) but that's quite a bit short of hypocritical to me.
  - shadowmint 9y ago
    > a caveat should follow advice like using unwrap and expect, perhaps a small blurb about how they should eschewed for better error handling when you want to catch the errors and make decisions because of them. That is literally the definition of hypocrisy; the behavior of people who do things that they tell other people not to do. "When you do this, do it like this, but properly with error handling." :P Anyhow, as I said its my oppinion that unwrap() is lazy, and `?`, `expect` and `assert!` cover the same functionality in more explicit and meaningful way. You're welcome to your own opinion.
    - jjnoakes 9y ago
      > That is literally the definition of hypocrisy; the behavior of people who do things that they tell other people not to do Except I'm not saying that at all. I said it's fine to use unwrap() or expect() if you want script-like default behavior (a developer-centric error message and a quick exit with a bad return code) and if you want something more than that, then use something better than unwrap() or expect(). There's no hypocrisy here. I think anyone should follow that advice. Me, you, a newb to Rust, a Rust veteran, anyone. Same advice.

jjnoakes 9y ago

> unwrap [...] causes application level crashes in way that is very much easier to avoid in other languages Unwrap does what just about every other language with exceptions-by-default does: it prints out a message for developers and exits. If you don't want that behavior, that's fine; in Rust you'd not use unwrap(), and in other languages you'd catch the exception. Now, I agree that if you are using a library which does unwrap() in Rust vs a library that throws an exception in Python, you have different situations. But unwrap() isn't meant to be used in libraries (or if it is, only for fatal errors which should be uncatchable). > Whats (sic) your justification for unwrap? I've never seen a meaningful justification for it other than not wanting to handle errors properly. That is the justification for it: you are writing a simple short script-like tool (or you are prototyping or exploring some problem through one-off or throw-away code) and you want any errors to immediately exit with a developer-centric message and failure code. unwrap() is perfect for this. It's the same justification for not catching every exception in other languages. Sometimes you are fine with an error printing a message and exiting.

MichaelGG 9y ago

>An application error (returned null) shouldn't abort your application with a hard error, no logs. Its just plain poor practice to use unwrap(). What? That's what every other language does. file.open("foo").read_line() If open fails it'll either throw or return null which will then cause read_line to throw a null pointer exception. Rust just makes things explicit here. Though it might be interesting if there was a special opt-in Deref impl for Result and Option so people could omit the unwrap and just get it implicitly, for the occasions when you don't want that explicitness.