alt Hacker NewsI really don't like how this article claims that the primary issue with Go's error handling is that the syntax is too verbose. I don't really care about that.
How about:
- Errors can be dropped silently or accidentally ignored
- function call results cannot be stored or passed around easily due to not being values
- errors.Is being necessary and the whole thing with 'nested' errors being a strange runtime thing that interacts poorly with the type system
- switching on errors being hard
- usage of sentinel values in the standard library
- poor interactions with generics making packages such as errgroup necessary
Did I miss anything?
Replies
> I really don't like how this article claims that the primary issue with Go's error handling is that the syntax is too verbose.
I don't believe this claim is made anywhere.
We've decided that we are not going to make any further attempts to change the syntax of error handling in the foreseeable future. That frees up attention to consider other issues (with errors or otherwise).
Just remember it took FOREVER for Go to support some form of generics. Go evolution happens at a glacial pace. That's a feature, not a bug....to many.
Agreed, 100%.
We're both Googlers here and this is so disappointing to be let down again by the Go team.
I agree with item #1, but it can be mitigated somewhat with dev tools like errcheck: https://github.com/kisielk/errcheck?tab=readme-ov-file
90% of working professionally in Go is contriving test cases to achieve statement coverage over each error return branch, something no one would ever do in a language with exceptions.