cmd/compile,wiki,spec: clarify whether or not the panics created in loop bodies should propagate to function iterators #71830
Comments
|
[edit]: sorry, pls ignored this comment. It looks I over-thought about it. It already works as such now. So the problem is much simpler than I thought. |
zigo101
changed the title
zigo101
changed the title
seankhliao
changed the title
|
cc @rsc |
|
CC @dr2chase |
mknyszek
added
the
NeedsInvestigation
ianlancetaylor
added
the
compiler/runtime
zigo101
changed the title
zigo101
changed the title
zigo101
changed the title
|
ping. IMO, this is a fundamental problem which should be resolved as early as possible, |
|
The following example is some ridiculous, but the crash message is absolutely inaccurate: package main
import "fmt"
import "time"
func main() {
for v := range abc {
time.Sleep(5 * time.Second)
fmt.Println(v)
}
}
func abc(yield func(string) bool) {
defer fmt.Println("bye")
go func() {
_ = yield("a")
}()
time.Sleep(time.Second)
}Output: [edit]: maybe a new issue should be opened for this: the A package main
import "fmt"
var c1 = make(chan int)
var c2 = make(chan int)
func main() {
for range abc {
c1 <- 1
<-c2
}
fmt.Println("c")
c2 <- 1
fmt.Println("d")
}
func abc(yield func() bool) {
defer func() {
fmt.Println("recover: ", recover())
}()
fmt.Println("a")
go func() {
_ = yield()
}()
<-c1
fmt.Println("b")
} |
|
The change actually breaks backward compatibility. However, the bad effect of the current design is larger than the breaking. |
|
Panics can propagate to different goroutines now. Intended? package main
import "fmt"
import "time"
func main() {
for range abc {
panic(123)
}
}
func abc(yield func() bool) {
for range time.Tick(time.Second) {
go func() {
defer func() {
fmt.Println("recover in go:", recover())
}()
_ = yield()
}()
}
}If a |
|
The following program prints package main
import "fmt"
func main() {
for v := range abc {
defer func() {
fmt.Println(recover())
}()
fmt.Println(v)
panic(789)
}
}
func abc(yield func(int) bool) {
defer yield(1)
panic(123)
} |
By the current doc, the loop body is viewed as being directly nested both in the innermost nesting function of the loop and in the
yieldfunction which is called in the iterator function.In my opinion, the loop body should be only viewed as directly nested both in the innermost nesting function of the loop.
In other words, when a function is used as an iterator, the
yieldcalls should viewed as being removed from the iterator function.The effect of the doc change is that panics created in loop body are not catch-able in the iterator function.
(Another explanation: the panics created in loop bodies don't propagate to iterator functions. The
yieldcall just returns afalsewhen panicking,)For example, the following two programs should have the same behavior, but they don't in 1.24.0 implementation. This is weird to users. By adopting the above explanations, then their behavior will become the same (the two
recovercalls should be both no-op).The text was updated successfully, but these errors were encountered: