4 ms·
Go error handling works well as is I think most of these proposals add a lot more complexity.
by lu4p 5y ago
Go error handling works well as is I think most of these proposals add a lot more complexity.
- thatswrong0 5y agoGo doesn't really have error handling.
- hactually 5y agoLiving up to your username eh?
- thatswrong0 5y agoIf you think type error interface { Error() string } and then if err != nil { return err } 10000x times counts as a legitimate error handling strategy, you either have an extremely low bar set or haven't used Go much. Then again, people seem to be okay with Golang allowing nil pointer exceptions to exist in 2021, so maybe the bar is underground.
- 37ef_ced3 5y agoAgreed. There's nothing wrong with it
- ebingdom 5y agoUsing product types instead of sum types to represent "success or error" is definitely something wrong with it. Product types should be used for "and", and sums should be used for "or".
- swagonomixxx 5y agoCan you explain why you think it's wrong?
- kadoban 5y agoBecause when you return `foo, err` , your caller has to remember not to use the foo. And when you're constructing your return values, often if you have an error, you won't have a real `foo` to give back, which raises the temptation to return a pointer-to-foo instead so you can give nil in that case. But then your caller has to check for the nonsense case where there's no error but also a nil foo. Usually what is meant is "I'll return a foo _or_ an error" but what go's type system encodes is "I'll give you a foo and maybe an error" or "I'll give you maybe a foo and maybe an error" depending on what choice you make.
- erik_seaberg 5y agoUninitialized struct values are a bad idea, but they’re allowed.
- ebingdom 5y agoBecause the typical situation with error handling is that there are two possible cases: (a) a function succeeds with some result, or (b) it fails with an error. A sum type represents those two possibilities exactly. In contrast, a product type says "I have both a result and an error", which makes no sense. However, if things can be nil, which is the norm in Go, then you can represent both (a) and (b) with a product type, but you also have two additional cases to worry about: (c) both the result and the error are present, and (d) both are nil (and what are you supposed to do in that situation?). When using static types, it is best to make as few nonsensical/illegal/invalid states representable as possible, so that you can rely on the compiler enforcing that they won't happen. Functional programmers have been saying this for decades, and these days Rust programmers are generally onboard with this too. Sum types are the categorical dual of product types, so it always seems unnatural to me when a language only has the latter and not the former. I think part of the problem is we don't teach category theory to programmers, so they never stop to consider the duals of things.
- kadoban 5y agoI'd say the problem is many programmers don't learn enough languages to know what they're missing, or if they do they only get as far as languages with the same semantics but slightly different syntax.
- chakkepolja 5y agoIn practice it doesn't impact much. It's not black and white. It's a tradeoff language complexity vs code robustness and I'm fine with it.