A lot of people complain about Go's repetitive err checking pattern, but it's very familiar if you've ever written systems code in C. If you aren't checking return values and errno from every system call (and able to log them), you're code is going to be impossible to debug.
Conversation
Replying to
The issue with the approach in Go is not that the errors need to be handled from each call. The issue is the language is inexpressive, overly verbose and forces massive amounts of duplicated code for this. It doesn't have a way to return a result or an error or to work with that.
2
4
It forces always returning both a result and an error, and it does that via a hard-wired multiple return value feature rather than a type like a tuple which would lend itself to less code repetition. Avoiding exceptions doesn't imply having this kind of verbosity / repetition.
2
2
Replying to
It seems like returning a tuple would also result in a lot of repetitive code to unpack and check the error value from it. What would that look like?
1
Replying to
Returning a tuple is also a bad implementation, because you don't actually want to return the result and the error, but rather either the result or the error. It would still be much better than the special-cased multiple return value since you can actually have code reuse for it.
As in you can write functions / methods taking (ResultType, ErrorType) and compose them together. Of course, that's not going to work very well without the ability to write code that's generic across types, which is tied into this too. Go is quite hostile towards code reuse.
2
4
Go has interfaces, which it could be using to support that kind of composition and code reuse. There's even an error interface already. I don't really understand going 90% of the way to making it work decently but then having the weird special cases and shortcuts that they use.