英文:
Why this program prints 421 in result?
问题
我无法理解，为什么这个程序打印出421而不是431？
package main
import "fmt"
var x int
func f() int {
x++
return x
}
func main() {
o := fmt.Println
defer o(f())
defer func() {
defer o(recover())
o(f())
}()
defer f()
defer recover()
panic(f())
}
下面是我猜测的注释：
package main
import "fmt"
var x int
func f() int {
x++
return x
}
func main() {
o := fmt.Println
defer o(f()) // x=1
defer func() {
defer o(recover()) // x=3 来自 panic（但如果我们执行这个程序，我们会看到2）
o(f()) // x=4
}()
defer f() // x=2
defer recover() //nil
panic(f()) // x=3
}
英文:
I can't to understand, why this program prints 421 instead of 431?
package main
import "fmt"
var x int
func f() int {
x++
return x
}
func main() {
o := fmt.Println
defer o(f())
defer func() {
defer o(recover())
o(f())
}()
defer f()
defer recover()
panic(f())
}
Below I added the comment how I guess:
package main
import "fmt"
var x int
func f() int {
x++
return x
}
func main() {
o := fmt.Println
defer o(f()) // x=1
defer func() {
defer o(recover()) // x=3 from panic (but if we ll execute this program we ll see 2)
o(f()) // x=4
}()
defer f() // x=2
defer recover() //nil
panic(f()) // x=3
}
答案1
得分: 5
defer不会调用函数，但它会立即评估其参数。只有在从延迟函数中调用recover()时，才会停止恐慌状态（defer recover()不符合此条件）。详见https://stackoverflow.com/questions/29518109/why-does-defer-recover-not-catch-panics/29518404#29518404
根据这个解释，我们来给代码行编号：
L1: o := fmt.Println
L2: defer o(f()) // x = 1
L3: defer func() {
L4: defer o(recover()) // recover()返回2
L5: o(f()) // x = 4，会被打印出来
L6: }()
L7: defer f() // panic之后：x = 3
L8: defer recover()
L9: panic(f()) // x = 2
上述代码的执行过程如下：
L2：评估o()的参数，调用f()，将x增加到1（稍后将打印出来）。o()尚未被调用。
L3：延迟函数尚未被调用，暂时跳过其整个函数体。
L7：f()尚未被调用，x保持为1。
L8：recover()尚未被调用。
L9：调用f()，将x增加到2，并返回该值，因此将2传递给panic()。
我们处于恐慌状态，因此现在执行延迟函数（按照后进先出的顺序）。
L8：调用recover()，但不会停止恐慌状态。
L7：现在调用f()，将x增加到3。
L3：现在执行这个匿名函数。
L4：recover()返回传递给panic()的值2，稍后将打印出来，但此时还没有，因为对o()的调用被延迟了。恐慌状态在此处停止。
L5：调用f()，将x增加到4，立即打印出来。
L4：现在执行延迟函数o()，打印上述值2。
L2：现在执行延迟函数o()，打印先前评估的值1。
程序结束。
英文:
defer does not call the function, but it does evaluate its arguments "immediately". Also a call to recover() only stops the panicing state if it gets called from a deferred function (defer recover() does not qualify for this). See https://stackoverflow.com/questions/29518109/why-does-defer-recover-not-catch-panics/29518404#29518404
In the light of this: Let's number the lines:
L1: o := fmt.Println
L2: defer o(f()) // x = 1
L3: defer func() {
L4: defer o(recover()) // recover() returns 2
L5: o(f()) // x = 4, it gets printed
L6: }()
L7: defer f() // after panic: x = 3
L8: defer recover()
L9: panic(f()) // x = 2
The execution of the above code will go like this:
L2: evaulates the params of o(), f() is called, x is incremented to 1 (this will be printed later). o() is not yet called.
L3: Deferred function is not called yet, skip its whole body for now.
L7: f() is not called yet, x remains 1.
L8: recover() is not called.
L9: f() is called, increments x to 2, and returns it, so 2 is passed to panic().
We're in a panicking state, so deferred functions are executed now (in LIFO order).
L8: recover() is called but does not stop the panicing state.
L7: f() is called now, increments x to 3.
L3: This anonymous function is now executed.
L4: recover() returns 2 (the value that was passed to panic()), this will be printed later, but not yet, as call to o() is deferred. Panicing state stops here.
L5: f() is called, increments x to 4, it gets printed right away.
L4: deferred function o() is now executed, printing the above value 2.
L2: deferred function o() is now executed, printing the previously evaluated value 1.
End of program.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论