Does Panic In One Goroutine Crash The
Fast recall
Quick revision
Core answer
Practical understanding of Panic Vs Error.
Repeating a definition without saying when to use it.
Give one trade-off and say how you would test it.
Interview-ready guide
Interview answer
It does, and this surprises people who expect exception-like isolation. Go's runtime does not try to unwind other goroutines or isolate the failure — the process exits. Every goroutine, including the main one and every in-flight request, dies immediately.
The consequence is a rule for real services: any goroutine you spawn gets its own deferred recover at its own boundary. The parent's recover doesn't cover the child — they're separate stacks. If a server accepts a connection and handles it in a goroutine, that handler needs a top-level recover that converts panics into a 500 (or at least a logged crash of that one request) rather than taking down the whole server with it.
// every spawned goroutine needs its own boundary
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("worker panic: %v", r) // this request dies; server lives
}
}()
handle(conn)
}()Does Panic In One Goroutine Crash The
Direct Answer
Yes. An unrecovered panic in any goroutine terminates the entire process — all goroutines die together. Each goroutine needs its own recover at its own boundary.
Deep Dive & Architecture
Mechanically, each goroutine has its own stack and unwind is per-stack. When goroutine B panics, the runtime unwinds B's stack; when it runs out without finding a recover, there is nothing else to do safely — the other goroutines are in arbitrary states, possibly holding locks mid-operation, and the runtime has no safe way to pause and clean them. Exit is the only honest option.
That's the deep reason the goroutine-recover pattern exists: the only code that can catch a goroutine's panic is code inside that goroutine. Libraries like net/http actually do this for you in the request handler — http.Handler panics are recovered per-connection and turned into a closed connection — which is why a nil-map write in one HTTP handler doesn't kill your whole web server. Know where your runtime draws that boundary for you and where you must draw it yourself.
Common Mistakes & Pitfalls
Repeating a definition without saying when to use it.
Check your understanding
Answer these without looking back at the article.
- What is Panic Vs Error, and when would you use it?
- When would you use Panic Vs Error in a real project?
- What is a common mistake when using Panic Vs Error?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.