Hacker News Reader

Comment by noelwelsh | Hacker News Reader

I feel this article misses the point in many cases. Take, for example, error handling. It's labourious in Go, but that's not the only issue. I'm not going to go into all the details in this comment (others have covered this at length) but:

1. Go's error handling has four possible cases (result and no error, no result and error, result and error, no result and no error) when only two make sense.

2. A consequence of the above is that it requires null values (nil in Go)

I don't see how this can be considered good design.

View on HN

> 1. Go's error handling has four possible cases (result and no error, no result and error, result and error, no result and no error) when only two make sense.

A partial success, that returns both a result and an error definitely makes sense. For example, you’re streaming data over a network, receive some bytes, but get disconnected before it’s complete. It would make sense to have both the data received so far as well as the error, in order to resume.

I’m sure there’s an appropriate situation for the 4th case as well.

Does it make sense for every function to have those four cases, though?

This is why it's table stakes for a decent type-system to have both product-types and sum-types. They comprise both sides of the coin, and you use the one that actually makes sense for the piece of code being written.

A justification for Go's deficient type-system I've seen repeatedly over the years, along the lines of "Well actually the occasional function can legitimately return both a result AND an error" is nonsensical. It's basically excusing giving 98% of error-returning functions a semantically wrong return type (a tuple) because it happens to be correct in 2% of cases.

Every function should have a semantically correct return type! If a product-type is occasionally correct for an error-returning function, use one just for those functions! And use a sum-type for the other 98% where that is correct for them!

Exactly. One can think of examples where these cases make sense, but there are many more examples where there are more cases (e.g. there many be multiple kinds of partial successes) or fewer (most functions, which either succeed or fail.)

Also, the design requires null values. A point which the replies have ignored.

Streaming data, there was no error but also no new data available.

That is an error :)

Your example doesn't make sense because that's not how the syscall works.

Go's Write makes a promise to not do short writes except on errors, which means it has to be a loop over write(2).

Interesting. Does it return both the amount of partially written data AND the error if it fails?

Yes. https://pkg.go.dev/io#Writer

I can think of situations where all four make sense. Not sure what you mean?

result+no error: data returned, no error happened. - Typical function call where you want some data.

no Result+error: nothing to return, error happened. - That typical call failed.

result+error: partial result, up to error. - Wrote x bytes to disk, then ran out of space.

no result+no error: nothing to return, no error. - Data for a passed query. Nothing came back, but that's not an error.

But not every situation. Make illegal state unreprestable is a good ideal.

> Go's error handling has four possible cases

If you consider (T, error) to be logically coupled, there is actually effectively an infinite number of cases. (T, U, error), (T, U, V, error), (T, U, V, W, error), etc. Although I suspect this take is suffering from trying to project idioms from another language onto Go.

(T, error) is just a special case of (T, E).

At least we can agree it is (T, E) and not (T or E).

Reply on news.ycombinator.com