4 ms·

It makes me sad to see the example. This is why I maintain `.unwrap()` is one of the worst things in rust. ...because people use it; and then say; 'but don't u

It makes me sad to see the example. This is why I maintain `.unwrap()` is one of the worst things in rust. ...because people use it; and then say; 'but don't use unwrap...'; and then use it, and your 'safe' language then happily crashes and burns everytime something goes wrong. Blogs and documentation are particularly prone to it. Result and option types are good; but if you're gonna have unwrap, you basically have to have exceptions as well (or some kind of panic recovery), because, people prefer to use it than use the verbose match statement. :/

zokier 9y ago
> ... because people use it; and then say; 'but don't use unwrap...'; and then use it, and your 'safe' language then happily crashes and burns everytime something goes wrong It might crash, but it doesn't burn, which is kinda the point of panic. Its behavior is well defined and predictable, which is great improvement over typical C UB.
bombless 9y ago
Well if people say "don't use unwrap", they're simply wrong.
jjnoakes 9y ago
> your 'safe' language then happily crashes and burns everytime something goes wrong I'm not sure why you put 'safe' in quotes here; nothing about 'unwrap()' (or even 'panic') is unsafe in the context of Rust. In fact, it acts just like Python would in the same circumstances: print a developer-centric message out and exit with a bad return code. What's unsafe about that? > if you're gonna have unwrap, you basically have to have exceptions as well Why do you think that? unwrap() is meant to be the same as throwing an uncatchable exception; if you want to throw an exception that you mean to catch somewhere, you should be using something else. > people prefer to use [unwrap()] than use the verbose match statement People may not be aware (which will come with time) but there are more than just those two choices when it comes to error handling in Rust.
- shadowmint 9y ago
  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.
jayflux 9y ago
Yeah I found this odd too. Rust docs say unwrap() shouldn't really be used, but through the rest of the documentation examples it's used everywhere. I suppose it's to keep the documentation simple and focused
- steveklabnik 9y ago
  Yes, that's why. When ? Can be used in main, we will switch to that en mass.
  - cjs_2 9y ago
    Which RFC is this?
    - steveklabnik 9y ago
      https://github.com/rust-lang/rfcs/pull/1937 https://github.com/rust-lang/rfcs/pull/1937
Ar-Curunir 9y ago
Unwrap doesn't make rust unsafe, it's not a segfault. You also don't have to use the verbose match statement when using options and results; you either propogate the error with ?/try or you provide a default value, or you panic (if the error should not be happening).
ordu 9y ago
I agree, its not a great idea to use unwrap() in production code, it is bad even when its safe to unwrap. But speaking about blogs... Why not to use .unwrap() there? Its simple, and allows to show some ideas without digging into error handling, just point to places where those handling should be placed. > but if you're gonna have unwrap, you basically have to have exceptions as well (or some kind of panic recovery) ... https://doc.rust-lang.org/1.9.0/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/1.9.0/std/panic/fn.catch_unwind.ht...

zokier 9y ago

> ... because people use it; and then say; 'but don't use unwrap...'; and then use it, and your 'safe' language then happily crashes and burns everytime something goes wrong It might crash, but it doesn't burn, which is kinda the point of panic. Its behavior is well defined and predictable, which is great improvement over typical C UB.

bombless 9y ago

Well if people say "don't use unwrap", they're simply wrong.

jjnoakes 9y ago

> your 'safe' language then happily crashes and burns everytime something goes wrong I'm not sure why you put 'safe' in quotes here; nothing about 'unwrap()' (or even 'panic') is unsafe in the context of Rust. In fact, it acts just like Python would in the same circumstances: print a developer-centric message out and exit with a bad return code. What's unsafe about that? > if you're gonna have unwrap, you basically have to have exceptions as well Why do you think that? unwrap() is meant to be the same as throwing an uncatchable exception; if you want to throw an exception that you mean to catch somewhere, you should be using something else. > people prefer to use [unwrap()] than use the verbose match statement People may not be aware (which will come with time) but there are more than just those two choices when it comes to error handling in Rust.

shadowmint 9y ago
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.

jayflux 9y ago

Yeah I found this odd too. Rust docs say unwrap() shouldn't really be used, but through the rest of the documentation examples it's used everywhere. I suppose it's to keep the documentation simple and focused

steveklabnik 9y ago
Yes, that's why. When ? Can be used in main, we will switch to that en mass.
- cjs_2 9y ago
  Which RFC is this?
  - steveklabnik 9y ago
    https://github.com/rust-lang/rfcs/pull/1937 https://github.com/rust-lang/rfcs/pull/1937

Ar-Curunir 9y ago

Unwrap doesn't make rust unsafe, it's not a segfault. You also don't have to use the verbose match statement when using options and results; you either propogate the error with ?/try or you provide a default value, or you panic (if the error should not be happening).

ordu 9y ago

I agree, its not a great idea to use unwrap() in production code, it is bad even when its safe to unwrap. But speaking about blogs... Why not to use .unwrap() there? Its simple, and allows to show some ideas without digging into error handling, just point to places where those handling should be placed. > but if you're gonna have unwrap, you basically have to have exceptions as well (or some kind of panic recovery) ... https://doc.rust-lang.org/1.9.0/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/1.9.0/std/panic/fn.catch_unwind.ht...