In Go, how do you capture a panic's stack trace inside the deferred function that recovers it?

## The problem When a Go program panics, the runtime walks up the goroutine's stack running deferred functions. A deferred function may call the builtin `recover()`, which stops the panic and returns the value that was passed to `panic(...)`. That value is all you get. If the panic was `panic("index out of range on shard map")`, you learn the message and nothing about *where* it happened. Logging only the recovered value produces the single most useless class of production log line: a message with no location. ## The two functions in runtime/debug The standard library answer lives in the `runtime/debug` package: - `debug.Stack() []byte` returns a formatted stack trace of **the goroutine that calls it**, as bytes. - `debug.PrintStack()` writes that same trace to standard error and returns nothing. Both are thin wrappers over `runtime.Stack`, which formats a trace into a caller-supplied buffer. `debug.Stack` picks the buffer for you: it starts at 1 KB and doubles until the whole trace fits, so you never get a silently clipped trace. The idiomatic recovery handler therefore looks like this: ```go defer func() { if r := recover(); r != nil { log.Printf("recovered: %v\n%s", r, debug.Stack()) } }() ``` Note `%s` on a `[]byte`: the trace is already formatted text, one line per frame pair (function, then file and line). ## Why the trace still shows the panicking function This is the part that surprises people, and it is the reason the pattern works at all. Deferred functions are not run after the stack has been unwound; they are run **by** the panic machinery while the frames beneath are still live. The runtime's `runtime.gopanic` was called from the function that panicked, and it in turn calls your deferred function. So the walk from your handler outward reads roughly: your deferred closure, then `runtime.gopanic`, then the function that panicked, then its callers. You get the fault site for free. The corollary is a real bug people ship: if you only remember the panic value inside the handler and format the stack somewhere later — after the deferred function returns, or in a goroutine you start from it — the panicking frames are gone, and you capture the stack of wherever you happen to be standing. Capture the bytes inside the deferred function, then pass those bytes around. ## Choosing between Stack and PrintStack `PrintStack` hardcodes standard error. In a library or a service with structured logging that is the wrong destination: you cannot attach a request id, you cannot rate-limit it, you cannot drop it in a test. `Stack` returns bytes, which the caller routes wherever it wants — a log field, an error report, a file, `io.Discard`. Prefer `Stack` in anything other than a throwaway program. The trace is per goroutine and only the current one. Nothing here shows you what the rest of the process is doing; that needs `runtime.Stack(buf, true)` or a goroutine profile, both of which pause the program and are a deliberate, separate decision. ## Cost and discipline Formatting a stack is not free — it walks frames and builds text — but a recovery handler runs once per panic, and a service that panics often enough for the formatting cost to matter has a much larger problem. What *does* matter is volume of output: an unbounded flood of multi-kilobyte traces can fill a disk or a log budget, so rate-limit the log call rather than the capture. Finally, recovering is a decision, not a reflex. A recovery handler that swallows the panic and logs a stack is appropriate at a request boundary, where one bad request should not take the process down. Recovering deep inside library code, where the caller's invariants are already broken, hides a bug. The stack you captured is what makes the difference reviewable: it says exactly which invariant broke and where.