3 ms·

I like how currently Go handles errors. It's not just about res1, err1Error = canFail() it's also about res1, successful1Bool = canFail() and many

by nirui 4y ago

I like how currently Go handles errors. It's not just about res1, err1Error = canFail() it's also about res1, successful1Bool = canFail() and many other ways that communicates an abort event. Current Go syntax handles every case in a consistent way, while the Rust-like syntax could only apply to error type specifically. But you don't always have to return an error if something failed (say Hashmap lookup, strings.Index, or even just `if res1.IsValid()` without `err1` all together), right? Another thing to add is that, syntax sugar such as `canFail()?` cannot help you with situations when you need to do something if the error happened, say: res2, err2 = canFail() if err2 != nil { res1.Drop() return err2 } you still have to write the flow in the old way. Rust can do that safely because it can automatically/magically drop things, Go can't and don't. All and all, the application for sugars such as `canFail()?` is very narrow. IMO not worth to consider add.

iainmerrick 4y ago
But you don't always have to return an error if something failed (say Hashmap lookup, strings.Index, or even just `if res1.IsValid()` without `err1` all together), right? No, a real error type is strictly better than a success/failure bool, I think. For something like a hashmap lookup, “false” becomes “NotFound” (say) which is a lot clearer. And you don’t need the “true” at all -- in that case you just have the result of the lookup. In your “res1.IsValid” example, would you still be returning a separate error result, just not using it? If so, that seems a little dangerous -- how can the compiler verify that you’re correctly handling errors? If instead there’s no explicit error return, it seems like you’re not really using the language’s built-in error handling, and it could work equally well in either Go or Rust.
- nirui 4y ago
  > would you still be returning a separate error result, just not using it It's a part of the examples for the statement "you don't always have to return an error", so... you don't return a separate error, you just abort at that point. Sorry I should have described it more clearly :)

by nirui 4y ago

iainmerrick 4y ago

But you don't always have to return an error if something failed (say Hashmap lookup, strings.Index, or even just `if res1.IsValid()` without `err1` all together), right? No, a real error type is strictly better than a success/failure bool, I think. For something like a hashmap lookup, “false” becomes “NotFound” (say) which is a lot clearer. And you don’t need the “true” at all -- in that case you just have the result of the lookup. In your “res1.IsValid” example, would you still be returning a separate error result, just not using it? If so, that seems a little dangerous -- how can the compiler verify that you’re correctly handling errors? If instead there’s no explicit error return, it seems like you’re not really using the language’s built-in error handling, and it could work equally well in either Go or Rust.

nirui 4y ago
> would you still be returning a separate error result, just not using it It's a part of the examples for the statement "you don't always have to return an error", so... you don't return a separate error, you just abort at that point. Sorry I should have described it more clearly :)