Hacker News Reader

Almost all error-related code in Go is just doing by hand what an exception system would do automatically: stop the current function and propagate it to the caller. The error is not being "dealt with" in a meaningful way except at the outermost layers of the onion (i.e. HTTP/RPC middleware converting it to a wire protocol error response) which could have used a try/catch anyway.

This was my view when I tried Go. I felt like I must be missing something but I’m yet to find out what.

Because transient errors shouldn’t be bubbled up immediately in case the issue is resolved quickly.

I prefer implicit error handling if exceptions are checked and defined as part of the contract, otherwise it’s definitely hard to trace.

I know the biggest complaint with checked exceptions is that people tend to just use catch all exceptions, but that’s just sloppy work. If they’re a junior, that’s when you teach them. Otherwise, people who do sloppy work are just sloppy everywhere anyway.

My issue with a lot of the best practice principles in SWE is that they were written for a perfect world. Even the best developers are going to do sloppy work on a Thursday afternoon after a day of shitty meetings during a week of almost no sleep because their babies were crying. Then there are there times when people have to cut corners because the business demands it. A million little things like that, which eventually leads to code bases which people like Uncle Bob will tell you were made by people who “misunderstood” the principles.

Simplicity works because it’s made for the real world. As I said I personally think Rust did it better, but if you asked me to come help a company fix a codebase I’d rather do it for a Go one than Rust.

Truthfully, I disagree. I’ve worked at a few different companies and I could absolutely rank them in the quality of their staff.

Been on teams where every individual was free to use their best judgement, we didn’t have a lot of documented processes, and… nothing ever went wrong. Everyone knew sloppy work would come back and bite, so they just didn’t ever do it. Deadlines were rarely a problem because everyone knew that you had to estimate in some extra time when presenting to stakeholders. And the team knew when to push back.

On the other hand, I’ve been on teams where you felt compelled to define every process with excruciating detail and yet experienced people somehow screwed up regularly. We didn’t even have hard deadlines so there was no excuse. The difference between implicit and explicit error handling would have not mattered.

At the end of the day, some of these teams got more done with far fewer failures.

Go has a philosophy to be simple, and this is explicit error handling at its simplest. You deal with errors exactly where they occur.

“if err != nil {return nil, err}” is the opposite of this philosophy. If you find yourself passing err up the call stack most of the times and most calls may return err, it’s still exception-driven code but without ergonomics.

It’s not simplicity, it’s head butt deep in the sand.

There is no other way - most error conditions can't be dealt with at the place where the error happened. A parseInt failing is meaningless at the local scope, the error handling depends on who is the caller.

Yes, that’s the point. The idea that you deal with errors locally doesn’t work. See also https://news.ycombinator.com/item?id=42038568

Golang needs monads. If by default it had a monad that propagated errors up the stack, then it would be much cleaner to work with, and should you need another behaviour you could install a different monad.