8 ms·

Huh? How exactly do you stay away from error handling? Even the most basic code on Earth has unwrap or expect in it. Show me one single library that doesn't un

Huh? How exactly do you stay away from error handling? Even the most basic code on Earth has unwrap or expect in it. Show me one single library that doesn't unwrap somewhere along the line.

abjKT26nO8 7y ago
Unwrapping results with pattern matching in "match" or "if let" lets you handle error conditions safely.
tov_objorkin 7y ago
unwrap() or expect() unconditionally smash program execution in case of error. Properly written program should handle such errors or use unwrap_or_* as fallback. The point is that unwrap/unsafe is breaking safety rules, user writing one know what hes doing or just don't bothering.
- jashmatthews 7y ago
  Unwrap and expect don’t violate any safety rules! If they did you’d need to wrap it in an unsafe block. https://doc.rust-lang.org/nomicon/unwinding.html https://doc.rust-lang.org/nomicon/unwinding.html
  - tov_objorkin 7y ago
    You're technically right, i mean if user aim for durable code then using unwrap is not desired behavior most of the time. For example pointer deference in C is implicit operation. In Rust user must choose explicitly how to handle Option/Result. Even if using unwrap not so harmful as using unsafe and didn't violate rules this is our deliberate choose to break "end-user safety".
crematoria 7y ago
You have it wrong. Only the most basic code on Earth has unwrap in it. Real-world code will either actually handle the error with `match`, forward it with `?`, or unwrap it with `except` iff it's sure that an error will not occur.
- arghwhat 7y ago
  > https://github.com/servo/servo/search?q=unwrap&unscoped_q=unwrap https://github.com/servo/servo/search?q=unwrap&unscoped_q=un... 522 results in servo. Granted, some (but not all) are in tests. `.unwrap()` is expected to be in every code base out there, as there is rarely much point in handling errors such as tainted mutex locks.
  - frenchman99 7y ago
    Most of the code you're linking to is unit tests, not application code.
    - arghwhat 7y ago
      No, I am thinking of application code. If you're trying to handle a poisoned mutex, you're doing something wrong.
  - crematoria 7y ago
    Yeah, most of that code is stuff like examples and tests, and most errors should be forwarded, not unwrapped. But yeah, of course if a resource that you depend on is potentially in an invalid state thanks to a thread crashing, it makes perfect sense to unwrap / expect.
- deleted 7y ago
  [deleted]
pornel 7y ago
`unwrap()` is "handling" errors by crashing the program, so it shouldn't really be used. It's common in examples, because it's usually the shortest/laziest code possible. However, all practical uses of `.unwrap()` have better alternatives, e.g. instead of if foo.is_some() { let unwrapped = foo.unwrap(); } you write: if let Some(unwrapped) = foo { } There are plenty of combinators like .map_or(), .ok_or()?, .filter_map() that deal with optional values gracefully.
- gdxhyrd 7y ago
  In libraries, yes. In applications, no. A lot of errors are fatal.
- cesarb 7y ago
  One of the commits in one of the first MRs in this article shows an example of a legitimate use of `unwrap()`... pub fn new(mut streams: Vec<TokenStream>) -> TokenStream { match streams.len() { 0 => TokenStream::empty(), 1 => streams.pop().unwrap(), _ => TokenStream::Stream(Lrc::new(streams)), } } Since `streams.pop()` will never return `None` when `streams.len()` is `1`. But I agree, most of the time using `match` (or its simplified form `if let`) or one of these combinators instead of `unwrap()` is better.
  - asdkhadsj 7y ago
    As a sidenote, I've been thinking about instituting an internal styling guide to discourage `unwrap()` in your scenario, in favor of `expect("impossibly missing")` or etc. The message helps a bit more, and I also want to avoid debug unwraps that were forgotten about. Though, the more I think about it the more a macro makes sense to me, purely for code search. If we used a macro, something like `impossible!(streams.pop())` then I can code search for `.unwrap` and `.expect`. Hmm
    - rrobukef 7y ago
      A compiler error if the code cannot be eliminated during optimization. Kind-of hacky, but it could be valuable as a new function.

Huh? How exactly do you stay away from error handling? Even the most basic code on Earth has unwrap or expect in it. Show me one single library that doesn't unwrap somewhere along the line.

abjKT26nO8 7y ago

Unwrapping results with pattern matching in "match" or "if let" lets you handle error conditions safely.

tov_objorkin 7y ago

unwrap() or expect() unconditionally smash program execution in case of error. Properly written program should handle such errors or use unwrap_or_* as fallback. The point is that unwrap/unsafe is breaking safety rules, user writing one know what hes doing or just don't bothering.

jashmatthews 7y ago
Unwrap and expect don’t violate any safety rules! If they did you’d need to wrap it in an unsafe block. https://doc.rust-lang.org/nomicon/unwinding.html https://doc.rust-lang.org/nomicon/unwinding.html
- tov_objorkin 7y ago
  You're technically right, i mean if user aim for durable code then using unwrap is not desired behavior most of the time. For example pointer deference in C is implicit operation. In Rust user must choose explicitly how to handle Option/Result. Even if using unwrap not so harmful as using unsafe and didn't violate rules this is our deliberate choose to break "end-user safety".

crematoria 7y ago

You have it wrong. Only the most basic code on Earth has unwrap in it. Real-world code will either actually handle the error with `match`, forward it with `?`, or unwrap it with `except` iff it's sure that an error will not occur.

arghwhat 7y ago
> https://github.com/servo/servo/search?q=unwrap&unscoped_q=unwrap https://github.com/servo/servo/search?q=unwrap&unscoped_q=un... 522 results in servo. Granted, some (but not all) are in tests. `.unwrap()` is expected to be in every code base out there, as there is rarely much point in handling errors such as tainted mutex locks.
- frenchman99 7y ago
  Most of the code you're linking to is unit tests, not application code.
  - arghwhat 7y ago
    No, I am thinking of application code. If you're trying to handle a poisoned mutex, you're doing something wrong.
- crematoria 7y ago
  Yeah, most of that code is stuff like examples and tests, and most errors should be forwarded, not unwrapped. But yeah, of course if a resource that you depend on is potentially in an invalid state thanks to a thread crashing, it makes perfect sense to unwrap / expect.
deleted 7y ago
[deleted]

pornel 7y ago

`unwrap()` is "handling" errors by crashing the program, so it shouldn't really be used. It's common in examples, because it's usually the shortest/laziest code possible. However, all practical uses of `.unwrap()` have better alternatives, e.g. instead of if foo.is_some() { let unwrapped = foo.unwrap(); } you write: if let Some(unwrapped) = foo { } There are plenty of combinators like .map_or(), .ok_or()?, .filter_map() that deal with optional values gracefully.

gdxhyrd 7y ago
In libraries, yes. In applications, no. A lot of errors are fatal.
cesarb 7y ago
One of the commits in one of the first MRs in this article shows an example of a legitimate use of `unwrap()`... pub fn new(mut streams: Vec<TokenStream>) -> TokenStream { match streams.len() { 0 => TokenStream::empty(), 1 => streams.pop().unwrap(), _ => TokenStream::Stream(Lrc::new(streams)), } } Since `streams.pop()` will never return `None` when `streams.len()` is `1`. But I agree, most of the time using `match` (or its simplified form `if let`) or one of these combinators instead of `unwrap()` is better.
- asdkhadsj 7y ago
  As a sidenote, I've been thinking about instituting an internal styling guide to discourage `unwrap()` in your scenario, in favor of `expect("impossibly missing")` or etc. The message helps a bit more, and I also want to avoid debug unwraps that were forgotten about. Though, the more I think about it the more a macro makes sense to me, purely for code search. If we used a macro, something like `impossible!(streams.pop())` then I can code search for `.unwrap` and `.expect`. Hmm
  - rrobukef 7y ago
    A compiler error if the code cannot be eliminated during optimization. Kind-of hacky, but it could be valuable as a new function.