3 ms·

It's error prone in that you aren't forced to handle the error. In languages such as Rust or Haskell, you have a Result type which can either be an Ok(val) or a

It's error prone in that you aren't forced to handle the error. In languages such as Rust or Haskell, you have a Result type which can either be an Ok(val) or an Err(err). In order to "unwrap" a Result, you have to check the error case. Basically there's a compile time guarantee that errors are handled.

Thaxll 7y ago
I'm not a Rust expert but afaik Rust doesn't enforce error checking since you explicitly need to unwrap(). It's very possible to panic because you forgot to check something. It's similar in Go since you can't compile with unused variable so you need to explicitly discard the error with _. Ex: result, _ := func() This is for multi-value returns, for single value you can even omit the _ https://golang.org/doc/effective_go.html#blank https://golang.org/doc/effective_go.html#blank
- jpittis 7y ago
  Having unwrap() in your Rust code is like littering your code base with panic(). It’s not appropriate to use in most production code, but is convenient in prototypes, examples and tests. Your example re Go errors is incorrect. The go compiler allows you to ignore errors in returns without any compiler error. For example err := doThingThatErrs() and doThingThatErrs() are both valid Go code.
  - Thaxll 7y ago
    My example is correct I explained all of that, multi values -> need to omit, single value can ignore everything.
    - jpittis 7y ago
      Yup. I misspoke. We’re both right.
  - edflsafoiewq 7y ago
    There's nothing wrong with unwrap. It's just an assert. Even a[i] is just shorthand for a.get(i).unwrap(). Asserts are definitely appropriate in production code, just not for handling run-time errors.
  - jbverschoor 7y ago
    Then how is this better than anything else? Except for syntactical sugar for: Try Return [Bla(), null] Catch err Return [null, err] End I do like this syntax better, bc the different scopes cause a lot of nesting

Thaxll 7y ago

I'm not a Rust expert but afaik Rust doesn't enforce error checking since you explicitly need to unwrap(). It's very possible to panic because you forgot to check something. It's similar in Go since you can't compile with unused variable so you need to explicitly discard the error with _. Ex: result, _ := func() This is for multi-value returns, for single value you can even omit the _ https://golang.org/doc/effective_go.html#blank https://golang.org/doc/effective_go.html#blank

jpittis 7y ago
Having unwrap() in your Rust code is like littering your code base with panic(). It’s not appropriate to use in most production code, but is convenient in prototypes, examples and tests. Your example re Go errors is incorrect. The go compiler allows you to ignore errors in returns without any compiler error. For example err := doThingThatErrs() and doThingThatErrs() are both valid Go code.
- Thaxll 7y ago
  My example is correct I explained all of that, multi values -> need to omit, single value can ignore everything.
  - jpittis 7y ago
    Yup. I misspoke. We’re both right.
- edflsafoiewq 7y ago
  There's nothing wrong with unwrap. It's just an assert. Even a[i] is just shorthand for a.get(i).unwrap(). Asserts are definitely appropriate in production code, just not for handling run-time errors.
- jbverschoor 7y ago
  Then how is this better than anything else? Except for syntactical sugar for: Try Return [Bla(), null] Catch err Return [null, err] End I do like this syntax better, bc the different scopes cause a lot of nesting