On Mon, Dec 8, 2025, 7:59 PM Robert Engels <[email protected]> wrote: > I don’t agree with that. The entire premise of RAII in C++ is to ensure > the proper management of resources in the context of exceptions. Sure you > can write code that doesn’t do that but it would be incorrect (and > difficult to debug). >
We must agree to disagree. It takes a lot more than RAII. Ian On Dec 8, 2025, at 9:46 PM, Ian Lance Taylor <[email protected]> wrote: > > > On Mon, Dec 8, 2025, 7:12 PM Robert Engels <[email protected]> wrote: > >> But how can you manage that in a library situation? The is no “throws” >> type declaration, so how can you be certain that the panic is actually >> raised by your code if you’re calling library routines in the same >> function? I guess you could wrap every call but that seems tedious - so it >> seems more “you can’t use panic/recover if you call ANY code not your own” >> - which also seems difficult to ensure. >> > > You call panic with a value of a type that you define, and you check for > that type when you call recover. See encoding/json or text/template. > > > Wouldn’t it be better (at least safer) to make the standard that you need >> to use defer to ensure resources are clean as ANY line might panic? or you >> need to run your app in a “any panic crashes mode” - which again seems >> problematic for internal library code. >> > > Sure, that is ideal, but it's frankly pointless to expect everybody to > write Go code like that. People empirically can't write C++ code like that, > and C++ has more support for it than Go does. > > Style recommendations need to be achievable. > > Ian > > > > Anyway I figure the ship has sailed but this seems an unfortunate gap. >> >> >> >> On Dec 8, 2025, at 9:02 PM, Ian Lance Taylor <[email protected]> wrote: >> >> On Mon, Dec 8, 2025, 5:15 PM Robert Engels <[email protected]> wrote: >> >>> Hmmm. Seems like there shouldn't be a panic and recover in the language >>> then - just always abort - or things are too risky. Or make it a private >>> stdlib localized/internal capability. >>> >> >> There is no problem with recovering your own calls to panic, and that is >> a useful technique. It is used by, for example, encoding/json. >> >> For that matter recovering a panic to log additional information can also >> be useful, as long as you don't try to continue executing normally. >> >> Ian >> >> >> >> > On Dec 8, 2025, at 6:36 PM, Ian Lance Taylor <[email protected]> wrote: >>> > >>> > 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/CAOyqgcX2grUYY%2Bto8qvZdXqx_E0xc2burQOX67aP74m50SC%2BOQ%40mail.gmail.com.
