panic, recover, and When to Fail

A file-not-found and a nil map write both break your program, but they are not the same kind of event, and Go gives them different mechanisms on purpose.

The file-not-found is an expected failure: the world is allowed to be that way, some caller can do something about it, and the condition was foreseeable when the API was designed. It is an error value — returned, wrapped, and decided on by the caller (The error Interface and Error Messages).

The nil map write is a programmer error: the code has violated an invariant — writing to a map that was never made, indexing past a slice, dereferencing nil, sending on a closed channel, a failed type assertion. No caller can sensibly "handle" it; the only honest response is to stop at the exact line where the assumption broke. Go's runtime does that with a panic:

m := map[string]int{}
m["x"] = 1 // panic: assignment to entry in nil map

A panic terminates the normal flow: no more statements in the current function, the stack unwinds, deferred calls run on the way out, and unless something calls recover, the program prints the panic value plus a stack trace and exits with a non-zero status.

The decision rule, stated as a question: could a competent caller distinguish this failure and choose a response? If yes, return an error — the caller might retry, fall back, or report 404. If no — if reaching this line means the program's own logic is broken — panic. A third category exists for programs at startup: a CLI that reads PORT=abc from its own config file may panic with a precise message rather than thread a strconv error through eight setup functions, because there is no caller left to decide. The panic's stack trace points at the exact bad line, which is more diagnostic than any returned error would be.

What you must not do is borrow the categories: panicking on a missing file turns a routine 404 into a crashed process, and recovering an invariant violation deep in a library turns a loud bug into a silent wrong answer. The next two chapters cover the mechanics that make both mistakes possible.

A panic does not jump blindly to the exit. It executes a precise sequence — and recover works only by plugging into that sequence.

func main() {
	defer fmt.Println("main defer 2")
	defer fmt.Println("main defer 1")
	risky()
	fmt.Println("after risky")
}

func risky() {
	defer func() {
		if r := recover(); r != nil {
			fmt.Println("recovered:", r)
		}
	}()
	panic("boom")
}
// recovered: boom
// main defer 1
// main defer 2

Walk the trace. panic("boom") starts unwinding risky — no statement after it runs. The deferred closure fires, recover() returns "boom", and the panic stops: risky returns normally, so main continues and prints after risky. Had the closure not called recover, unwinding would have continued into main, running its two defers newest-first, and the program would crash with the original panic.

Three rules define when recover works, and they explain most "why didn't my recover work?" debugging sessions:

1. It must be called directly by a deferred function. recover() in the function body does nothing — during normal execution it returns nil, and during a panic in the same frame it is too late to intercept anything.
2. It must be in the goroutine that is panicking. A deferred recover in a different goroutine cannot catch your panic; each goroutine unwinds its own stack (Goroutine Basics).
3. It returns nil when nothing is panicking. The idiomatic if r := recover(); r != nil guard works because of this — the deferred closure is harmless on the success path.

Also worth internalising: runtime failures are panics too. Index out of range, nil pointer dereference, integer division by zero, x.(T) assertion failure — a single recover at your process boundary catches them all, which is why one recovery layer can convert "the process died" into "this request got a 500 with a stack trace in the log." Recovery does not fix anything; it decides where the failure is reported instead of at the bottom of the stack.

The single legitimate place to recover is a boundary where you can make the failure whole for one unit of work: one HTTP request, one job, one loaded plugin — while keeping the process alive.

func recoveryMiddleware(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		defer func() {
			if rec := recover(); rec != nil {
				log.Printf("panic %s %s: %v\n%s", r.Method, r.URL.Path, rec, debug.Stack())
				http.Error(w, "internal server error", http.StatusInternalServerError)
			}
		}()
		next.ServeHTTP(w, r)
	})
}

The handler goroutine survives, the client gets a 500, and the stack trace lands in the log for the on-call engineer. Note that net/http already does exactly this per connection — a handler panic kills that connection and gets logged, not the server — so writing your own layer is about controlling the response shape and the logging, not about preventing process death.

Now the mistakes, so you can see why "boundary" is doing work in that sentence:

Recovering mid-library. A getUser function that recovers a nil-pointer panic and returns (User{}, nil) hides a real bug behind a plausible zero value. The invariant is still violated; the caller is now acting on wrong data. If your function cannot make the failure whole, let it propagate to a caller that can.

Recovering and swallowing. defer recover() with no logging converts crashes into silent misbehavior — the hardest failure class to debug, because nothing fails visibly and nothing is recorded.

Recovering in a goroutine you did not create. A panic inside go worker() needs its own defer func(){ recover() }() inside that goroutine; a recover in the spawner's stack will not see it. This is also why an unrecovered panic in any goroutine takes down the entire process, not just the goroutine.

The shape to remember: errors travel up as values; panics travel up as control flow; both need an owner. The owner of an error is the layer that decides the response. The owner of a panic is the edge of the system — the handler, the job runner, the test harness — where "log everything, answer 500, keep serving" is a coherent decision.

Exported Go code carries an implicit contract with its callers, and panic discipline is part of it. A function's documentation should be able to answer one question: which conditions come back as errors, and which conditions mean the caller is broken?

Two helper shapes cover most legitimate panics. In main-adjacent code, a must helper turns setup failures into immediate, well-located crashes:

func mustParseInt(s string) int {
	n, err := strconv.Atoi(s)
	if err != nil {
		panic(fmt.Errorf("invalid integer %q in config: %w", s, err))
	}
	return n
}

The program cannot run without this value, so failing loudly at startup beats threading the error through five setup functions where it would be ignored anyway. In library code, the mirrored helper is the recover-and-wrap that leaves the panic type intact for the boundary to log:

defer func() {
	if r := recover(); r != nil {
		err = fmt.Errorf("job %d panicked: %v", id, r)
	}
}()

(That form must run in the same goroutine as the panic — fine for a synchronous job runner, impossible across go statements.) The sharpest interview answer on this topic is the asymmetry: libraries return errors and almost never recover; binaries recover at their boundaries and rarely need to panic. Panics handle "my code is broken"; errors handle "the request failed." Keeping them in their lanes is what makes a Go codebase's failure behaviour predictable to read before you run it.