Hacker News Reader

Comment by tyingq | Hacker News Reader

Probably complaining from someone used to exceptions and/or assertions, where there is perhaps less boilerplate and manual verification that context bubbles to the right place.

You can get there either way, but what you're used to weighs heavily.

For your example, depending on my experience, knowing that 1!=2 in some code I'm using directly might be more meaningful or actionable than "out of filehandles for accept()" in some deep chain of dependencies I know little about. Just depends on what you're used to.

View on HN

Or anyone who's used a language where errors aren't as stringly-typed as Go and where the compiler can enforce error handling. Exceptions have benefits and drawbacks, but any language that can return a Result type will have better error handling than Go in basically every way.

In Go, `error` is an interface, which means you can return anything that implements the `Error() string` method as an `error`.

Yeah, but 99% of libs won't return anything with additional accessible structure.

Yeah I think the point is, errors shouldn't be overloaded with too much extra structure. They should be errors. If additional structure is needed, it should probably be sent separately via the common multiple returns idiom in Go.

Additional structure like, say, a numeric error code? An HttpError could definitely contain the corresponding status code.

But I think the bigger point is that, for libraries, errors should be an enumerated set of possible error conditions, not strings. You say "additional structure", I say the duplicate filename, the invalid email address or, crucially, the error that caused the error...chaining errors is very useful. The multiple returns idiom in Go may make this possible, but it's hacky and strictly worse than languages that can utilize generics and a more richly-typed set of errors.

The point I'm making here is that everyone knows 1!=2. It's not helpful for a test to tell you that because then you have to go hunting around to figure out what is wrong instead of it just giving you at least a rough idea right away. It does not depend on what you're used to.

I get that part. I'm saying Go doesn't fix stupid either. I can panic 6 layers into a dependency chain with a verbose error message that helps nobody.

It's often easier to fix 1!=2 if I know the entire error stack than it is to know exactly what happened where, but not the path down.

Like as obtuse as 1!=2 is, with exceptions, I might more easily recognize it as a reference leak.

Reply on news.ycombinator.com