You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In go 1.13, but probably any version of go, a runtime.Goexit call can cancel a panic (example from @go101):
package main
import "runtime"
func main() {
c := make(chan struct{})
go func() {
defer close(c)
// The Goexit signal shadows the
// "bye" panic, but it should not.
defer runtime.Goexit()
panic("bye")
}()
<-c
}
When you run this program, instead of getting a panic that terminates the program, you get a normal termination with no error. And generally, when a goroutine is panicking, a call to runtime.Goexit will just end the goroutine, but will cancel the panic, so the whole program may continue running.
This is not a big deal, since it has been like this for a long time and people are unlikely to run into it, but seems unexpected/incorrect.
One solution would be just to say that runtime.Goexit() is a no-op if we are in the middle of a panicking sequence. The slight downside to such a solution is that turning runtime.Goexit() to a no-op might be surprising and violate some programmer assumptions (especially if the runtime.Goexit call is buried deep within some other function/module), maybe leading to a second panic.
The text was updated successfully, but these errors were encountered:
In go 1.13, but probably any version of go, a runtime.Goexit call can cancel a panic (example from @go101):
When you run this program, instead of getting a panic that terminates the program, you get a normal termination with no error. And generally, when a goroutine is panicking, a call to runtime.Goexit will just end the goroutine, but will cancel the panic, so the whole program may continue running.
This is not a big deal, since it has been like this for a long time and people are unlikely to run into it, but seems unexpected/incorrect.
One solution would be just to say that runtime.Goexit() is a no-op if we are in the middle of a panicking sequence. The slight downside to such a solution is that turning runtime.Goexit() to a no-op might be surprising and violate some programmer assumptions (especially if the runtime.Goexit call is buried deep within some other function/module), maybe leading to a second panic.
The text was updated successfully, but these errors were encountered: