Hacker News Reader

Comment by danenania | Hacker News Reader

I have no problem with Go’s error handling. It’s not elegant, but it works, and that’s very much in keeping with the pragmatic spirit of Go.

I’m actually kind of surprised that it’s the top complaint among Go devs. I always thought it was more something that people who don’t use Go much complain about.

My personal pet issue is lack of strict null checks—and I’m similarly surprised this doesn’t get more discussion. It’s a way bigger problem in practice than error handling. It makes programs crash in production all the time, whereas error handling is basically just a question of syntax sugar. Please just give me a way to mark a field in a struct required so the compiler can eliminate nil dereference panics as a class of error. It’s opt-in like generics, so I don’t see why it would be controversial to anyone?

View on HN

I have 2 problems.

It's too easy to accidentally write `if err == nil` instead of `if err != nil`. I have even seen LLMs erroneously generate the first instead of the latter. And since it's such a tiny difference and the code is riddled with `if err != nil`, it's hard to catch at review time.

Second, you're not forced by the language to do anything with the error at all. There are cases where `err` is used in a function that not handling the `err` return value from a specific function silently compiles. E.g.

    x, err := strconv.Atoi(s1)
     if err != nil {
      panic(err)
     }
     y, err := strconv.Atoi(s2)

    fmt.Println(x, y)

I think accidentally allowing such bugs, and making them hard to spot, is a serious design flaw in the language.

I guess those are fair criticisms in the abstract, but personally I can’t recall a single time either has caused a bug for me in practice. I also can’t ever recall seeing an LLM or autocomplete mess it up (just my personal experience—I’m sure it can happen).

> It’s opt-in like generics, so I don’t see why it would be controversial to anyone?

It "breaks" the language in fundamental ways — much more fundamental than syntactic sugar for error handling — by making zero values and thus zero initialisation invalid.

You even get this as a fun interaction with generics:

    func Zero[T any]() T {
        var v T
        return v
    }

I don’t see how it breaks anything if it’s opt-in. By default you get the current behavior with zero value initialization if that’s what you want (and in many cases it is). But if you’d rather force an explicit value to be supplied, what’s the harm?

> I don’t see how it breaks anything if it’s opt-in?

Zero values are a fundamental, non-optional, "feature" of Go.

> But if you’d rather force an explicit value to be supplied, what’s the harm?

What happens if you use the function above with your type?

Or reflect.Zero?

If it would only complain on struct literals that are missing the value (and force a nil check before access if the zero value is nil to prevent panics), that would be enough for me. In that case, your Zero function and reflect.Zero can keep working as-is.

Then I fail to see the point, that is trivial to lint, just enable the exhauststruct checker.

I wasn't aware of it—will check it out, thanks.

Reply on news.ycombinator.com