4 ms·

It looks like maybe the goroutine in that example doesn't actually get a chance to run before the program stops. If the main function lasts longer, then you'll

It looks like maybe the goroutine in that example doesn't actually get a chance to run before the program stops. If the main function lasts longer, then you'll see the effect of the panic. See https://goplay.tools/snippet/8SFlFkZ2P0y https://goplay.tools/snippet/8SFlFkZ2P0y Also, see the Go spec: https://golang.org/ref/spec#Handling_panics 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.

kodah 5y ago
Yeah, very interesting. it seems highly inconsistent even when using a waitgroup: https://goplay.tools/snippet/X2c7lZGTqww https://goplay.tools/snippet/X2c7lZGTqww 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.
- GauntletWizard 5y ago
  Your use of the waitgroup is off; Because the Add instruction is inside the goroutine, it may not run until after wg.Done is called, which will return immediately. 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.
  - kodah 5y ago
    You're right about the Add(1) and defer. defer in itself is pretty interesting in how it's called. Basically there's the main body of your function and then a list of things to do before return, of which defers get added to. So, your theory is correct. 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.

kodah 5y ago

Yeah, very interesting. it seems highly inconsistent even when using a waitgroup: https://goplay.tools/snippet/X2c7lZGTqww https://goplay.tools/snippet/X2c7lZGTqww 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.

GauntletWizard 5y ago
Your use of the waitgroup is off; Because the Add instruction is inside the goroutine, it may not run until after wg.Done is called, which will return immediately. 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.
- kodah 5y ago
  You're right about the Add(1) and defer. defer in itself is pretty interesting in how it's called. Basically there's the main body of your function and then a list of things to do before return, of which defers get added to. So, your theory is correct. 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.