Thanks, Ian, this is very helpful. I’ll open an issue in the Go repository suggesting that the net/http documentation be made more explicit: although the HTTP server has built-in panic recovery, it should not be treated as a best practice pattern. The general guidance should be to let unexpected panics crash the program, unless explicitly recovering from a panic you triggered and fully understand.
Do you know if there is an official Go document that states this clearly? It seems like an important detail to have in formal documentation rather than buried in discussion threads, which can be harder to find and consume. I did find a few places discussing this, but they all seem to be personal blog posts or discussion threads: • https://github.com/golang/go/issues/25245 • https://iximiuz.com/en/posts/go-http-handlers-panic-and-deadlocks/ • https://eli.thegreenplace.net/2018/on-the-uses-and-misuses-of-panics-in-go/ • https://groups.google.com/g/golang-dev/c/rXs4TG1gdXw/m/7BQ29S4NPrgJ Thanks again for the clarification. On Monday, December 8, 2025 at 4:44:32 PM UTC-3 Ian Lance Taylor wrote: > On Mon, Dec 8, 2025 at 11:25 AM Max Claus <[email protected]> wrote: > > > > I recently discovered that I had a misconception about how panic > recovery works, especially in HTTP handlers. I wrote an article explaining > that misunderstanding and suggested using more recover calls for panics in > goroutines started from HTTP handler requests (link to article). That > seemed like a reasonable approach based on the http package documentation: > > > > > If ServeHTTP panics, the server (the caller of ServeHTTP) assumes that > the effect of the panic was isolated to the active request. It recovers the > panic, logs a stack trace to the server error log, and either closes the > network connection or sends an HTTP/2 RST_STREAM, depending on the HTTP > protocol. (reference) > > > > Reading that, I thought it would be a natural pattern to follow the same > logic for goroutines started from HTTP requests. However, the feedback I > received on Reddit from other engineers suggested that this is considered a > bad practice, and that the built-in recovery mechanism in the HTTP server > was a historical mistake that the Go team supposedly regrets. (link to > reddit thread) > > > > I’d like to understand this better. Is it actually considered bad > practice? And does the Go team really regret the built-in panic recovery in > HTTP handlers? Aside from the Google Go style guide and various opinions > from engineers online, I haven’t been able to find any official Go document > or article that clearly states this. (link to Google style guide, link to > someone commenting about it too). > > Yes, in general the Go team considers the fact that the net/http > server recovers panic to be a historical mistake. > > Go code in practice does not attempt to be safe in the presence of > panics in code that it calls. This means that in practice a panic can > leave data structures and locks in an inconsistent state. If the panic > is recovered, the future behavior of the program is unpredictable. > > As a general guideline, only use recover for a panic that you call > yourself. If you recover a panic and it's not what you expected, pass > the recovered value to a new call to panic. For example, see how the > encoding/json or text/template packages handle recovering panics. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/81db0d37-ecce-4826-98a9-8ca1f4e06c81n%40googlegroups.com.
