Why does Go compile a call whose returned error you never check?

## The language rule Go has two famous "unused" compile errors, and neither of them covers a return value. - An **unused local variable** is a compile error: `declared and not used`. - An **unused import** is a compile error. - An **unused return value** is perfectly legal. That last one is not an oversight. A function call is an *expression statement* in Go's grammar: writing `f.Close()` on a line by itself is as valid as writing `doWork()`. The compiler has no idea that `error` is special — it is an ordinary interface type in the standard library, not a language construct with rules attached. So this compiles: ```go f.Close() // error return discarded _ = f.Close() // error return discarded, deliberately _, _ = w.Write(b) // n and err both discarded ``` and this does not: ```go err := f.Close() // declared and not used ``` Multi-value returns are where the blank identifier becomes mandatory rather than stylistic. You cannot assign two results to one variable, so `w.Write(b)` either gets consumed or gets blanked. ## Why reviewers care about which form you used Both forms produce the same machine code and the same silence at runtime. What differs is what the next reader can conclude. - `f.Close()` reads as *nobody thought about it*. It is indistinguishable from a forgotten check. - `_ = f.Close()` reads as *somebody decided*. A reviewer can then ask the only interesting question: was the decision right? That is why the idiom in review-heavy codebases is to write the blank assignment with a short comment — `_ = f.Close() // read-only, nothing buffered` — rather than to leave a bare call and argue about it in every pull request. ## What the toolchain does and does not do for you `go vet` does **not** report unchecked error returns. Its `unusedresult` check covers only a small fixed list of pure functions whose results are pointless to throw away — things like `fmt.Sprintf` and `errors.New`, where discarding the value means the call did nothing at all. Everything else, including every `Close`, `Flush` and `Write`, is outside vet's remit and is left to lint tooling and to humans. The practical consequence for a team: a build that is green tells you nothing about whether errors are handled. Only review, or a linter you have deliberately added to CI, does. ## When discarding really is fine The anti-pattern is not "an error was discarded", it is "an error was discarded and nobody can tell whether that was intended". Defensible discards share three properties: no data is at risk, no caller decision depends on the result, and no operator would want to be told. Typical examples: - Closing a file you opened only for **reading**. Nothing was buffered on your side; a failure to close costs you a descriptor at most. - `fmt.Println` to standard output in a short-lived command-line tool. - Removing a scratch file during cleanup, where a failure changes nothing you would act on. Write those as `_ = x()` with a comment and they will survive review. ## When it is a bug Invert the three properties and you have the write path. A nightly job that reads CSV exports and writes a rolled-up file has data at risk on every single call: the record write, the flush of whatever writer is wrapping the file, and the close of the file itself. Each returned error you drop there is a class of failure that turns into *fewer rows in the output and an exit code of zero* — the worst possible pairing, because every downstream consumer trusts the file. ## The interview point The question is testing whether you know that Go's error handling is a **convention enforced by people**, not a rule enforced by the compiler. Candidates who say "Go forces you to handle errors" have confused the visible `if err != nil` style with a guarantee that does not exist. What Go actually gives you is that the error is *there*, in the return list, impossible to overlook by accident when reading — and impossible for the compiler to make you read.