Golang runtime: recover calls in loop body of ranging over iterators doesn't take effect

Go version

go version go1.24.0 linux/amd64

Output of go env in your module/workspace:

.

What did you do?

package main

import "fmt"

func main() {
    defer foo()
    panic(123)
}

func foo() {
    for i := range iter {
        fmt.Println(i, recover()) // 0 <nil>
    }
}

func iter(yield func(int) bool) {
    yield(0)
}

What did you see happen?

0 <nil>
panic: 123

goroutine 1 [running]:
main.main()

What did you expect to see?

0 123

Comment From: zigo101

Some like https://github.com/golang/go/issues/71675, but different.

Comment From: zigo101

BTW, I'm not sure whether or not the panic should be caught in the following code. Now it doesn't.

package main

import "fmt"

func main() {
    defer foo()
    panic(123)
}

func foo() {
    for range iter {}
}

func iter(yield func(int) bool) {
    fmt.Println(">", recover()) // > <nil>
    yield(0)
}

Comment From: gabyhelp

Related Issues

• runtime: recover added in range-over-func loop body doesn't stop panic propagation / segfaults printing error #71675
• runtime: confusing panic on parallel calls to yield function #68897
• iter: `iter.Pull` should forward panics and `runtime.Goexit` [freeze exception] #67712 (closed)
• runtime: can't recover #50512 (closed)
• runtime: recover is ineffective in some interface method calls #5406 (closed)
• panic when range-func return nil #69042 (closed)

Related Documentation

• Go Wiki: Rangefunc Experiment > What happens if the loop body panics? Or if the iterator function panics?

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

Comment From: dmitshur

CC @golang/runtime.

Comment From: mknyszek

In triage, we think this is almost certainly the same bug as #71675.

Comment From: zigo101

It looks to me that in https://github.com/golang/go/issues/71675, something was done incorrectly.

However, for the current issue, something was forgotten to do.

Comment From: cherrymui

While the symptoms look different, the underlying cause is probably the same -- recover matched to the wrong frame. And the fix is probably the same.

Comment From: dr2chase

This is not a duplicate; the fix for #71675 does not fix this.

Comment From: TapirLiu

Will this be fixed in Go 1.26?