Hacker News Reader

Comment by JamesMcMinn | Hacker News Reader

I'm left wondering why the switch was made in the first place. I spend about half my time coding in Go and love the language, but if I wasn't looking for easier concurrency or a speed boost, I wouldn't re-write an existing code base in Go. It's a lot of work to do just to revert a short time later.

The majority of comments are fair, although I'd disagree with it being C2.0 and err != nil getting old - I much prefer it to exceptions.

View on HN

I know of two cases where companies picked Go because it was in the headlines on HN ("we switched from X to Go" stories were pretty common a few years) and also "because Google supports, so it is going to be huge". Now two years later, there is regret and gnashing of teeth. Mostly due to now having to deal with new errors, not everyone knowing Go well enough, destabilized working code. One company loves ease of deployment though -- a single binary. Can't argue against it there.

I feel like you can't always handle every error. For instance if you're using a lot of third party libs that you aren't entirely familiar with, you may not be familiar with every possible error a given method call can throw. To complicate the issue error messages are often cryptic, to the point where even if you do catch it it is an entirely pointless exercise.

In this situation I feel like try: except Exception as e: is infinitely better then a half-dozen if err != nils.

Go was essentially designed with the idea that you shouldn't ignore errors. However, if you really don't care about errors, you can simply ignore them:

  result, _ := thirdparty.ReturnsError()

That ignores the error but then silently does the wrong thing when one is thrown. That's different to exceptions where you bail the function instead of proceeding as if nothing went wrong

Most of the time I end up writing if err != nil { return nil, err }. This seems better than a simple panic to me it allows the function to return, executing any deferred functions and doing any necessary cleanup.

If I had any complaint it would be that go could offer some way to setup default handling that simply returns zero and error for any unhanded errors.

I know the same thing can be done with try, catch finally but then you have the same problem of needing to know what errors may be returned so you can make sure an wrap that call in a try statement.

Won't gofmt turn that into 3 lines?

Yes, I just kept it together for brevity.

I both prefer error returns to exceptions and find Go's implementation of error returns tedious. There are many other possible implementations that avoid the constant boilerplate. I've seen alternatives that exist in other languages and ideas for a syntax that might make sense in Go elsewhere in this thread, and there are surely others elsewhere.

Reply on news.ycombinator.com