https://goplay.tools/snippet/am2vcq5JYFr
This is an example I made. Can you show how that would change to cause the problem you're describing?
This is an example I made. Can you show how that would change to cause the problem you're describing?
Also, see the Go spec: https://golang.org/ref/spec#Handling_panics
> Next, any deferred functions run by F's caller are run, and so on up to any deferred by the top-level function in the executing goroutine. At that point, the program is terminated and the error condition is reported, including the value of the argument to panic.
It looks like, assuming it makes it to the top of the current goroutine, then it should be killing the whole program.
Personally I don't use panics or deal in them that much, mainly because stack traces with multiple goroutines are unbelievable. I much prefer errors.
Still, that made it less flaky for a bit, but the it printed again! And I realized what else is going on: There's actually time between when the deferred functions are executed and the program exits! Which is fascinating, but unlikely to matter in practice. It brings me to another question: do deferred statements still get called when there's a panic on a different goroutine? And the answer seems to be no; adding a deferred print to the main function does not print.
I think intuitively I probably knew that a panic in a goroutine will shut down the main thread, it just didn't occur logically to me when I read it; which is an interesting paradox. Maybe that's a me-thing though.