Deferred Calls and Panics

## What `defer` is actually attached to When the Go runtime executes a `defer` statement, it records a pending call **for the frame of the function that is currently executing**. There is no block-level or loop-level bookkeeping anywhere in the language or the runtime: braces do not create a defer scope, and neither does a loop iteration. The only event that drains a frame's deferred calls is that frame going away. So `defer` inside a `for` body means "do this once per iteration, later, all at once, when the function returns" — which is almost never what someone writing resource cleanup intends. ## The shape of the bug A file-rotation CLI walks a tree (say with `filepath.WalkDir`) and, for each path, opens the file, streams it somewhere, and defers the close: ```go for _, p := range paths { f, err := os.Open(p) if err != nil { return err } defer f.Close() // ... use f ... } ``` After iteration 1 there is one pending `Close`. After iteration 5,000 there are 5,000 pending `Close` calls and 5,000 open descriptors, because the enclosing function has not returned yet. Two things grow together: the operating-system descriptors, and the frame's defer list itself (each pending call needs its own record, and a defer inside a loop is exactly the case the compiler cannot optimise away into inline code). ## How it shows up The process does not crash at the defer; it crashes at the *next* `os.Open`, which returns an error whose text ends in `too many open files`. That is the operating system refusing a new descriptor because the process is at its limit. The tell that separates this from a genuine leak elsewhere is the shape of the curve: the open-descriptor count for the process rises monotonically for the whole run and then drops to nothing the instant the function returns — the descriptors were never leaked, merely held far too long. A reader onboarding to the codebase often misreads this as "we forgot to close somewhere". The `Close` is right there in the source, which is what makes the bug persuasive. ## The idiomatic fix: one function call per iteration Because `defer` fires when a *function call* returns, give each iteration its own call: ```go for _, p := range paths { if err := handle(p); err != nil { return err } } func handle(p string) error { f, err := os.Open(p) if err != nil { return err } defer f.Close() // ... use f ... return nil } ``` Now the descriptor is released at the end of every iteration, and the defer list never holds more than one entry. An immediately invoked function literal inside the loop does the same job when a named helper would be overkill, though a named helper usually reads better and is easier to test. The other legitimate option is to drop `defer` in the loop and close explicitly at each exit path from the body. That is more error-prone precisely because a loop body typically has several `continue`/`break`/early-`return` paths, and each one has to remember the close — which is the reason `defer` exists in the first place. ## Why the language does not make `defer` block-scoped Block-scoped cleanup would need the compiler and runtime to track and drain pending calls at every brace, and it would break the single most common use of the feature: registering cleanup at the top of a function so that *every* return path, including ones added months later, is covered. Function scope is what makes `defer mu.Unlock()` on line two a durable guarantee. The loop case is the price of that choice, and the price is paid by extracting a function. ## What to say in an interview Name the scope rule first ("defer is per function call, not per block"), then the consequence (N pending calls, N held resources), then the fix (extract the body into a function so each iteration is its own call), then the observable (`too many open files`, descriptor count climbing for the life of the loop). That ordering shows you understand the mechanism rather than having memorised a rule of thumb.