Sure, it is clean looking, but there is no actual error processing in this code. It is just "ok, it failed, not my problem, stop and go up the stack". If you ha

Sure, it is clean looking, but there is no actual error processing in this code. It is just "ok, it failed, not my problem, stop and go up the stack". If you have exceptions, that's the equivalent of not doing anything at all. Sometimes, that's the thing to do, but overall, I don't think it is a good practice. Failures are as important at the "happy path". Connection failed? You really have to think about what to do. Use defaults or cached values instead? Panic? Print a helpful error message? Going up the stack and letting the caller deal with the problem is a possibility, a common one, but it has to be a deliberate choice. That's what I like about the go style of error processing: it is deliberate. And indeed I find the criticized go code in the article to actually be better than the "clean" solution, because there are actual error messages. What you may end up with when you don't actually process errors are unhelpful messages like "unable to retrieve contact data: permission denied" because, for example, you couldn't read a configuration file because you don't have access to it. It happens when the developer just passed the system error up the stack, which the "clean" solution encourages.