[geofft]

I think you can syntactically state that anything where the check is on the second return value (which is, by convention, the error return) is a "simple error check", and their rule for if statements is always for things that come from a first return value.

For instance, this would not be a simple error check:

    server, err := find_current_server()
    if server != nil {
        ...
    }

because if find_current_server() believes that it's a non-exceptional case that there might be no server at all (i.e., it might return nil, nil instead of nil and an error), then you absolutely want to handle that case.

[germainelong]

What if the second returned variable is not err, but the code using it assumes it is? (the code breaks the convention) This will not be accounted for. This means with that in mind a lot more discipline must be used to analyse the code that is being used in that module.

[geofft]

I think that is highly unusual in Go (but someone who actively uses Go would have to correct me).

Besides, this syntactic rule is not implemented by code but by the author and reviewer, who should know what the function returns. (And shouldn't name it "err", then.) They're doing the best they can in a language without syntactic support for what they want, I think.

[AlexCoventry]

Go pretty much assumes decent editor support, which should inform you of the type of err as you use it. It's not perfect, but it hasn't been a problem for me in practice, so far.