Hacker News Reader

Comment by dcu | Hacker News Reader

yeah go/rust error handling is great. Much better than exceptions which make the code hard to read since you can't easily predict where is the flow going to jump. And the multiple-return is very convenient in this case too.

Also, with Go's approach you have to either explicitly ignore the error or deal with it.

View on HN

My problem with Go (and I love the language a lot) is that a lot of my error handling is "stop execution in the function and bubble the error up", which results in my code being littered with if err != nil { return err }, which is a bit annoying.

If I'm doing something wrong here I'd love to know it.

You're not doing anything wrong. And I think it's better that way, to have the error possibilities visible and very understandable. All the context you need to see the error handling is in front of you, not hidden in 25 different files. That's a blessing.

The only other idea (and it isn't a very good one) I've seen is to put the error as a parameter and let the called function early return if given a non-nil error: http://play.golang.org/p/bRdFWBZp5r

Sometimes other techniques are more useful.

- you can collect errors in a function and return them once or provide an extra method, like http://golang.org/pkg/bufio/#Scanner.Err

- you can type switch on the error; maybe there are errors that you can recover/retry locally, such as connection errors, or general io failures - so you do not need to pass back all errors to the caller

More on errors: https://blog.golang.org/errors-are-values

This annoyed me to no end working in node.js, having to manually re-raise errors at every step is pretty tiresome and error prone (no pun intended).

I've recently started working in node after spending some time in Go-land and the reverse applies to me. The code I'm writing is a mix of js + Go and I find that in JS I have no sense for what can go wrong since it's not obvious to me if a method will throw an exception or not. However, with Go it forces me to think about my error path.

I do find littering code with err checks can be annoying and ended up reaching a compromise. For all code that is likely to be part of an externally public package I use 'if err !=' checks. For application level code that will be internal to my application (and internal to the file I'm working in) I use a small library [1] I wrote, that uses the panic-defer-recover style talked about in the Go documents for internal error handling [2].

However, I find that in most situations I usually prefer to not use panic-defer-recover, with if checks providing more clarity.

[1] https://github.com/surullabs/fault [2] http://golang.org/doc/effective_go.html#recover

That's exactly why exceptions were invented. They aren't really as magical and hard to understand as the parent poster seems to think. In a theoretical sense, exceptions just do if err != nil { return err } on every call automatically.

I feel like so many developers have been so damaged by Java's approach to exception handling that, of course, error codes seem simpler by comparison. I can't help by feel the recent push-back against exceptions is a step backwards in many situations. A whole generation of developers will have to re-learn the pain that lead to the development of exceptions in the first place.

Reply on news.ycombinator.com