sourcegraph / conc

Better structured concurrency for go

Home Page:https://about.sourcegraph.com/blog/building-conc-better-structured-concurrency-for-go

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

wg.safeWait() is need , i think no one want to see panic in the release

welldonexing opened this issue · comments

func (h *WaitGroup) Wait() {
h.wg.Wait()

// Propagate a panic if we caught one from a child goroutine
// h.pc.Repanic()

}
h.pc.Repanic() is for debug ,i think . why to crash that. and it doesn't "safer"

Hi @welldonexing! While I do think it's reasonable to add something like func (w *WaitGroup) WaitSafe() *RecoveredPanic for people who want to handle panics manually, I also think that repanicking is still the best default and not just for debugging.

The value that WaitGroup adds is that it keeps panics in scope. A very common pattern with Go applications is to put a panic handler at the top level of an API request handler, then return an error if it catches a panic. However, if there are any goroutines spawned as part of handling that request, panics in those will crash the process if unhandled. By propagating any panics, wg.Wait() provides value by stopping the process from crashing and allowing the user to define how panics should be handled for their application.

Importantly, I don't think there is a viable alternative for a library. We need to do something with the panics. Ignoring them isn't a good option. Logging them isn't a good option. Returning them makes it so that the user has to manually handle it on every call. In my view, re-raising the panic is the only good option that doesn't lose information, doesn't overburden the user, and still provides the user full control.

I've created #29 as a followup to this. I'll move discussion about the design of a SafeWait() there. Thanks for the suggestion!