golang-troubleshooting

Read the stack trace to find the exact line, then trace backward to where the nil value originated rather than adding a nil check at the crash site. Common causes include unchecked error returns, map lookups returning zero values, and uninitialized struct fields.

Run tests or the program with the -race flag, such as go test -race ./... or go run -race main.go. The race detector slows execution roughly 10x but reliably reports data races with full stack traces of conflicting accesses.

A typed nil pointer wrapped in an error interface is not a nil interface, so err != nil evaluates true. Fix it by returning nil explicitly from the function instead of returning a typed nil variable like var err *MyError.

No, recover() only catches panics in the same goroutine where it is deferred. A panic in a child goroutine crashes the entire program, so each goroutine must include its own defer/recover block.

Capture the goroutine profile via /debug/pprof/goroutine?debug=2 and look for goroutines stuck in chan receive. In tests, use go.uber.org/goleak, and monitor runtime.NumGoroutine() over time in production.

Use Delve for breakpoint-based stepping through code and inspecting variables during development or test debugging. Use pprof for profiling CPU, heap, goroutines, mutexes, and blocking behavior in running services, including production.