In Go, how do you make a deferred f.Close() failure reach the caller as the function's error?

### Why a bare deferred Close cannot report anything `defer f.Close()` schedules a call whose result is discarded — the deferred call has no caller to return to. To capture the value you need somewhere to put it, and the only variable still alive and still connected to the caller at that moment is a **named result**. ### The mechanics When a function with a named result returns, the return value is assigned to that named variable first, and only then do the deferred calls run. Because the deferred closure captures the variable rather than a copy of it, an assignment inside the closure changes what the caller receives. ```go func writeAll(path string, data []byte) (err error) { f, err := os.Create(path) if err != nil { return err } defer func() { if cerr := f.Close(); cerr != nil && err == nil { err = cerr } }() _, err = f.Write(data) return err } ``` At the top level of the body, `f, err := os.Create(path)` reuses the named `err` rather than creating a new one, because short variable declaration only needs one new name on the left and the named result lives in the function's outermost scope. Inside an `if` or `for` block the same line would introduce a different variable, and the closure would keep reading the outer one. ### The precedence rule, and the bug people write instead The guard `cerr != nil && err == nil` encodes a policy: **the first failure is the interesting one.** A write that fails usually makes the close fail too, and the write error is the one with the useful context. Two wrong variants show up constantly: - `defer func() { err = f.Close() }()` — a successful close assigns nil over a real write error, so the function reports success on a failed run. This is strictly worse than not capturing the error at all. - `defer func() { if cerr := f.Close(); cerr != nil { err = cerr } }()` — closer, but a failing close now masks the write error that caused it, and you debug the wrong layer. ### Keeping both errors Since Go 1.20, `errors.Join` takes any number of errors, drops the nil ones, and returns nil when they are all nil. That makes a one-line deferred closure possible: ```go defer func() { err = errors.Join(err, f.Close()) }() ``` The joined value still matches both underlying errors under `errors.Is`, so callers testing for a specific condition are not broken by the extra error. The tradeoff is a message that concatenates two lines; when a function's error is going to be shown to a user rather than inspected, the explicit `err == nil` guard usually reads better. ### Multiple layers When there is a buffered writer over the file, the closure has to finish the layers innermost first, and every layer's error deserves the same treatment: ```go defer func() { if ferr := w.Flush(); ferr != nil && err == nil { err = ferr } if cerr := f.Close(); cerr != nil && err == nil { err = cerr } }() ``` A single closure that finishes the whole stack is easier to reason about than a chain of separate deferred statements, because the precedence between the layers is written down instead of implied. ### When not to bother This machinery buys nothing on a handle you only read from: there is no unwritten data at stake, and a close error there is noise you cannot act on. Adding a named result and a closure to every function that opens a file makes the ones that genuinely matter harder to spot. Use it where the function's job was to produce bytes, and leave the read paths plain. ### The review test Given a function that opens a file for writing, ask two questions: can a failure at close change the caller's decision, and would a successful close ever hide an earlier failure? The first decides whether you need the named result; the second decides the guard.