cmd/vet: check for http.Error followed by other statements in handler?

[dsnet]

Using go1.6

I recently saw code that did the following:

func serveHTTP(resp http.ResponseWriter, req *http.Request) {
    ...

    if err := foo(); err != nil {
        http.Error(resp, err.Error(), http.StatusInternalServerError)
    }

    if err := bar(); err != nil {
        http.Error(resp, err.Error(), http.StatusInternalServerError)
    }
}

The assumption made was that http.Error() terminates the current handler in some magical way. Instead, Error simply sets the headers and writes the body message, and it is the programmer's responsibility to return. We should document this.

[bradfitz]

I also wonder whether we should write a go vet check for this too. But we should only do so if this is a common problem. Is it easy for somebody to AST-grep all public Go source code and look for an http.Error with reachable statements afterwards? (/cc @sqs, @alandonovan)

We can start with documenting this first, of course.

[gopherbot]

CL https://golang.org/cl/21836 mentions this issue.

[alandonovan]

Based on a quick scan of Google's Go code base, I think such a check would find several errors, but not without false positives. Sometimes an http.Error call and its subsequent return statement are separated by logging statements or error-counter increments. We could exempt any function calls with "log" or "Error" (or within Google, "Add") in their names. The false positives are easy to work around by transposing statements.

[bradfitz]

Re-opening to consider vet checks.

[dmitshur]

Is it easy for somebody to AST-grep all public Go source code and look for an http.Error with reachable statements afterwards?

/cc @dominikh ;)