When a Go function returns a non-nil error, what may the caller assume about its other return values?

## The convention Go has no way to say "this result is only valid on success" in the type system, so it says it by convention: **when the returned error is non-nil, the other results carry no meaning and are the zero value for their type.** That means: - a `*T` result is `nil`, - a slice or map result is `nil`, - a numeric result is `0`, - a string result is `""`, - a struct result is the zero struct. And because a caller reads that convention as a promise, a function you write should honour it. Returning a half-filled struct next to a non-nil error invites the caller to use it. ## The failure this prevents Go does not unwind. A non-nil error is a value sitting in a variable; execution continues to the next statement whatever that value is. So the check is not really "check the error" — it is "stop". ```go resp, err := http.Get(upstream) if err != nil { log.Print(err) // noticed, but did not stop } io.Copy(w, resp.Body) // panic: resp is nil ``` Here the failure was even *observed*, and the program still crashes: `resp` is nil, so evaluating `resp.Body` dereferences a nil pointer. This is the single most common shape of nil-dereference panic in Go, and it is a direct consequence of failures being values rather than control flow. In an exception language the throw itself would have skipped the second call; in Go only your `return` does. The same bug hides behind a deferred cleanup written too early. `defer resp.Body.Close()` placed *before* the error check panics on the spot, because the receiver expression `resp.Body` is evaluated when the `defer` statement runs, not at return. ## Documented exceptions The convention is a default, not a law, and the standard library documents where it differs. The most useful example is copying: ```go n, err := io.Copy(dst, src) ``` `n` is the number of bytes that actually reached `dst`, and it is meaningful even when `err` is non-nil. That is exactly what an operator wants after a mid-stream failure: an upstream that died on the first byte and one that died after 900 MB produce the same error text but very different `n`. The rule to take away is: **the doc comment is the contract; the zero-value convention is what you assume when the doc is silent.** If you are unsure whether a partial result is usable, read the function's documentation rather than guessing from the shape of the signature. ## Writing functions that honour it When you author a `(T, error)` function: 1. Return the zero value on every failure path. Do not return a partially constructed value "in case it is useful". 2. If a partial result genuinely helps the caller — bytes written, rows processed, items successfully parsed — return it, and say so in the doc comment in one sentence. 3. Never return a non-nil error together with a result whose validity depends on which failure happened. That forces the caller to inspect the error to know whether the value is readable, which is exactly the coupling the convention exists to avoid. ## Reviewing for it The pattern to look for in a review is an `if err != nil` block whose body does not end the function: no `return`, no `continue`, no `break`, no `os.Exit`. That block is not a check, it is a comment with side effects. Every use of the sibling result below it is a live nil dereference waiting for the first production failure, and unit tests usually never hit it because the happy path always returns a non-nil value. The second thing to look for is a result being used *between* the call and the check — an argument built from it, a length taken, a field read. Once the value has been touched, moving the check later does not help.