Hacker News new | past | comments | ask | show | jobs | submit login

> And in cases where a function returns an error and a value (where the error generally indicates the validity of the value), you'll get a compile error if you don't check the error.

This compiles:

    package main
    import "errors"
    func main() {
        x, err := f()
        if err != nil {
            return
        }
        y, err := g()
        h(x, y)
    }
    func f() (x int, err error) { return 1000, nil }
    func g() (y int, err error) { err = errors.New("boo"); return }
    func h(x, y int) { println(x/y) }
(I do write Go most days and rather like it, but apologists for its weak parts are legion)



Pretty sure errcheck will catch that too. The thing that bugs me is the people that make up problems that are not at all problems in real day to day coding.


This looks more like a bug. The second err is a valid redeclaration, and so should be checked for usage on it's own. Though the redeclaration through multiple assignment is itself a bit of a wart that the programmer hast to be wary of, so it may not be a big deal.

In any case, the go compiler is very helpful in most cases, and better tooling can improve things further.


FYI the second use is just assignment, that's why it's not caught by the unused variable rule.


Ah right. It only shadows if it's a new scope.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: