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 <https://maxclaus.dev/blog/goroutine-panic-and-recover/>). 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 <https://pkg.go.dev/net/http#Handler>)* 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 <https://www.reddit.com/r/golang/comments/1ph0xyk/goroutine_panic_and_recover/> ) 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 <https://google.github.io/styleguide/go/best-practices#program-checks-and-panics>, link to someone commenting about it too <https://github.com/oklog/run/issues/10#issuecomment-476298524>). -- 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/f8cbdf90-49a0-42c1-bd1c-c2c7c426e103n%40googlegroups.com.
