Defer Close Pattern

The pattern, executed:

func readFile(name string) error {
    f, err := os.Open(name)
    if err != nil {
        return err       // error path — no leak (nothing acquired yet)
    }
    defer f.Close()     // EVERY exit from here: file closes

    // ... work with f ...
    return nil
}

The discipline: defer f.Close() comes AFTER the error check (you can't close a nil file) and BEFORE any other return path — that's the invariant: every Open followed immediately by its deferred Close.

The subtlety interviewers probe: Close returns an error too (buffered writes may fail on close — deferred close silently discards it). For read-only files, the discard is safe. For writes, the pattern that surfaces close errors:

func writeFile(name string) error {
    f, err := os.Create(name)
    if err != nil { return err }
    defer f.Close()

    if _, err := f.WriteString("data"); err != nil {
        return err       // f.Close runs via defer
    }
    return f.Close()    // explicit close to catch the error
}

The pattern with a named return + defer is the general form:

func writeFile(name string) (err error) {
    f, err := os.Create(name)
    if err != nil { return err }
    defer func() {
        if cerr := f.Close(); cerr != nil && err == nil {
            err = cerr  // surface the close error
        }
    }()
    // ... work ...
    return
}

The general resource rule: whatever has a Cleanup/Close/Unlock, the defer goes at acquisition — files, network connections, mutexes, response bodies (the HTTP client's resp.Body defer is the same discipline).