Hacker News Reader

Comment by masklinn | Hacker News Reader

Go's error handling remains verbose, unsafe and error-prone compared to more modern languages which use return values for error signaling (Erlang, MLs, Haskell, Rust).

The problem is not that Go's error handling requires more thinking or efforts, it's that it is bad, and while that's an improvement from C's terrible error handling it's still nowhere near good enough, let alone good (unless you consider C's error handling to be good enough in the first place).

View on HN

Saying that a particular language feature is bad in a vacuum is a ridiculous endeavor because you aren't accounting for trade offs in the language as a whole. The most obvious way to "fix" Go error handling is to add some form of sum types to the language. But this comes with its own set of trade offs that have been discussed at great length on golang-nuts.

Feel free to enlighten us specifically about how they are better.

In Go, you're not returning a sum type, so it's down to the programmer to remember that the "real" return value is likely toxic waste when its copassenger the error return value is non-nil.

What's the practical problem of this, though? The (varname, err := thing) pattern is sprinkled all throughout the language, enough to where it should be instinctive for a coder to check the err value when doing anything that could fail.

Of course we can put up with anything. The topic of the subthread is that it's halfassed and has a better alternative.

A major hit to readability. Every call site where you want to check for an error requires adding another level of nesting.

That's a different issue. Pattern-matching a sum-type value, though safer, would be "noise" too.

Correct me if I'm wrong, but I believe with sum types you can chain together multiple calls then pattern match once at the end. In Go you have to check at each call.

If you have an unusual amount of error handling cluttering up your code in Go, then you can use `panic` (with `defer` and `recover` to convert panics to errors in the public interface).

I've been programming without if statements. It feels a lot better using pattern matching instead of if statements.

Wait, that's it? The difference between bad (with italics!) and awesome is being able to reference the garbage half of a multiple return?

I'm not the GP. Ask them for their full story.

You can embed metadata with sum types on a return object. You can then use the metadata programmatically to increase correctness, enhance readability, and reduce boilerplate. This blog post goes into more details:

http://fsharpforfunandprofit.com/posts/recipe-part2/#series-...

Ok thanks for filling in the blank.

> You're not returning a sum type so it's down to convention to remember that the "real" return value is effectively garbage when the error return value is non-nil.

There are many cases where this is not true.

> more modern languages which use return values for error signaling

I must be missing something.. Returning a value in Go for error signaling is the way to signal errors in Go.

> I must be missing something.. Returning a value in Go for error signaling is the way to signal errors in Go.

Yes? That's the point, I'm comparing it to more modern languages which signal error "the same way", by opposition to languages implementing different high-level methods of error signaling. The clause is there to explicitly point out that I'm not considering or talking about exceptions and conditions-based error signaling.

Maybe it'd have been clearer if I'd written "languages which also use return values"?

Yeah, I parsed this incorrectly as well. It was an ambiguous statement.

You posted a while back that "scope inference (in Python) sucks". Could you expand on that. I know it's totally unrelated to this thread but I was really hoping to understand what you meant.

Thanks!

Reply on news.ycombinator.com