Let’s talk about nil pointer checks in Go. You want to prevent panics in production, but that doesn’t start with a deferred recover. It starts with defensive programming. Check your inputs, check your bounds, and check pointers for nil before dereferencing them. I’ve started to see more nil checks in Go code. In the right place, they are necessary for writing safe code. In the wrong place, they are a sign that the code has stopped being clear about what can and cannot be nil. I have noticed this pattern more in generated code, but this symptom is not new and is not limited to AI.
  • cockmushroom@reddthat.com
    1·
    10 days ago

    As someone who’s never written go professionally and never contributed code that needed a nil check to open source, I have a rule whereby I never return nil pointers (other than slices) unless i’m returning a non-nil error and vis versa. Is that enough? I did read through the article but I didn’t feel like it reached a clearer conclusion than “you can avoid checking by having standards” and I assume that what I’ve been doing is missing something.