Exploring Error Handling Patterns in Go
8thlight.com
Exploring Error Handling Patterns in Go
1–10 of 80 posts
Re: Exploring Error Handling Patterns in Go
#2I appreciated the article, but the error handling in Go just bugs me. So verbose...
The built-in tool does not even warn about unused errors... not `go build`, and not `go vet`. What's more important, an ignored error or an unused import?
Re: Exploring Error Handling Patterns in Go
#3I appreciated the article, but the error handling in Go just bugs me. So verbose... The built-in tool does not even warn about unused errors... not `go build`, and not `go vet`. What's more important, an ignored error or an unused import? https://play.golang.org/p/j-oXsZz51ki
That's by design -- programmer's choice.
Re: Exploring Error Handling Patterns in Go
#4if err != nil
return err
if err != nil return err
if err != nil return err
https://github.com/docker/cli/search?q=%22if+err+%21%3D+nil%...
https://github.com/kubernetes/kubernetes/search?q=%22if+err+...
https://github.com/coreos/etcd/search?q=%22return+err%22&uns...
https://github.com/influxdata/influxdb/search?q=%22if+err+%2...
The reality of Go's error handling is that you just implement exactly what exception bubbling does painfully by hand.
Re: Exploring Error Handling Patterns in Go
#5I appreciated the article, but the error handling in Go just bugs me. So verbose... The built-in tool does not even warn about unused errors... not `go build`, and not `go vet`. What's more important, an ignored error or an unused import? https://play.golang.org/p/j-oXsZz51ki
That's by design -- programmer's choice.
And it’s—bluntly—a terrible design.
Re: Exploring Error Handling Patterns in Go
#6I appreciated the article, but the error handling in Go just bugs me. So verbose... The built-in tool does not even warn about unused errors... not `go build`, and not `go vet`. What's more important, an ignored error or an unused import? https://play.golang.org/p/j-oXsZz51ki
That's by design -- programmer's choice.
I don't understand.
Go errors out on unused imports, but you can type "import _ foo.com/unused-import" to not error out.
Why doesn't 'errors.New("asdf")' error out and require you to instead write '_ = errors.New("asdf")' to ignore the result
I think the real answer is not that it's intentional design, but rather that the original compiler was not powerful enough to implement that feature easily... and once go hit 1., it was impossible for them to add new warnings or errors because there are no warnings and errors are backwards incompatible.
Sure, that means developers use third-party tools for warnings because the go compiler refuses to ever have warnings (that compromises the pure beauty of the language obviously), but at least that means it's only the users that have to deal with the complexity of using more tools, the compiler developers can ignore it.
Re: Exploring Error Handling Patterns in Go
#7if err != nil return err if err != nil return err if err != nil return err https://github.com/docker/cli/search?q=%22if+err+%21%3D+nil%... https://github.com/kubernetes/kubernetes/search?q=%22if+err+... https://github.com/coreos/etcd/search?q=%22return+err%22&uns... https://github.com/influxdata/influxdb/search?q=%22if+err+%2... The reality of Go's error handling is that you just implement exactly what exception bubb…
This is not correct. Exceptions do different things than report an error. They unwind the stack. That's why they are called exceptions and not errors.
One important benefit of Go's error handling pattern is readability. With exceptions, it's not easy to see who handles it and where. There is indeed less code, and that's nice for the writer, but from the reader perspective, error handling becomes obscure. And from the quality control point if view, this becomes unsafe.
Re: Exploring Error Handling Patterns in Go
#8if err != nil return err if err != nil return err if err != nil return err https://github.com/docker/cli/search?q=%22if+err+%21%3D+nil%... https://github.com/kubernetes/kubernetes/search?q=%22if+err+... https://github.com/coreos/etcd/search?q=%22return+err%22&uns... https://github.com/influxdata/influxdb/search?q=%22if+err+%2... The reality of Go's error handling is that you just implement exactly what exception bubb…
The pattern is the programmer's choice. Here's a contrary example/approach:
Re: Exploring Error Handling Patterns in Go
#9if err != nil return err if err != nil return err if err != nil return err https://github.com/docker/cli/search?q=%22if+err+%21%3D+nil%... https://github.com/kubernetes/kubernetes/search?q=%22if+err+... https://github.com/coreos/etcd/search?q=%22return+err%22&uns... https://github.com/influxdata/influxdb/search?q=%22if+err+%2... The reality of Go's error handling is that you just implement exactly what exception bubb…
This is not correct. Exceptions do different things than report an error. They unwind the stack. That's why they are called exceptions and not errors. One important benefit of Go's error handling pattern is readability. With exceptions, it's not easy to see who handles it and where. There is indeed less code, and that's nice for the writer, but from the reader perspective, error handling becomes obscure. And from the…
[deleted]
Re: Exploring Error Handling Patterns in Go
#10if err != nil return err if err != nil return err if err != nil return err https://github.com/docker/cli/search?q=%22if+err+%21%3D+nil%... https://github.com/kubernetes/kubernetes/search?q=%22if+err+... https://github.com/coreos/etcd/search?q=%22return+err%22&uns... https://github.com/influxdata/influxdb/search?q=%22if+err+%2... The reality of Go's error handling is that you just implement exactly what exception bubb…
This is not correct. Exceptions do different things than report an error. They unwind the stack. That's why they are called exceptions and not errors. One important benefit of Go's error handling pattern is readability. With exceptions, it's not easy to see who handles it and where. There is indeed less code, and that's nice for the writer, but from the reader perspective, error handling becomes obscure. And from the…
At the cost of making the entire logic's readability less which to me is more important than sometimes getting confused where errors bubble up to.
The philosophy is different when, for example the author of Ruby wanted to make coding fun for programmers and does a good job at it and Go is sticking to 'this must be right' approach and breaks some people's heart.
Personally I'd appreciate being more 'fun'.