On Mon, Dec 8, 2025 at 3:23 PM Robert Engels <[email protected]> wrote: > > Hi Ian. Can you add more detail on “leave data structures and locks in an > inconsistent state”. Isn’t that the purpose of defer - especially in the > context of code that may panic - to ensure that is not the case?
Yes, defer can indeed be used that way. Still, I believe what I said is true: Go code in practice does not attempt to be safe in the presence of panics in code that it calls. I will stress "in practice." Ian > On Dec 8, 2025, at 1:37 PM, Ian Lance Taylor <[email protected]> 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/CAOyqgcVLmE9KxnYTC1rbJHE9E1WHpSdGsVwHDT2CH%3DfK_2ZoGQ%40mail.gmail.com. > > -- 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/CAOyqgcXSCow8nxbv4ye4o9oMbg6AEs0TM_7iWcO-XG8DudSOqg%40mail.gmail.com.
