為什麼嵌套的'defer”無法恢復 Go 中的恐慌？

揭秘巢狀延遲函數恢復無效的原因

在 Golang 中，recover() 是處理異常和預防異常的關鍵機制。恐慌的蔓延。然而，當在巢狀延遲函數中使用recover() 時，會出現一個有趣的現象。與預期相反，儘管存在嵌套延遲，恐慌仍然可能發生。

為了說明這種異常情況，請考慮以下程式碼：

package main

import "fmt"

func printRecover() {
    r := recover()
    fmt.Println("Recovered:", r)
}

func main() {
    // Direct deferred call to recover()
    defer printRecover()

    panic("OMG!")
}

執行時，此程式碼按預期運行：

Recovered: OMG!

但是，當我們將printRecover()包含在巢狀的延遲中時函數：

package main

import "fmt"

func printRecover() {
    r := recover()
    fmt.Println("Recovered:", r)
}

func main() {
    // Nested deferred call to recover()
    defer func() {
        printRecover()
    }()

    panic("OMG!")
}

結果變化：

Recovered: <nil>
panic: OMG!

goroutine 1 [running]:
main.main()
    /tmp/sandbox898315096/main.go:15 +0x60

差異源自於recover()的獨特行為。根據Go 規範，recover():

• 回傳nil 如果：

  • 恐慌參數為nil
  • goroutine> 不是恐慌🎜>recover()沒有被延遲函數直接調用function
在巢狀延遲情況下，recover() 不是由最外層延遲函數直接調用，而是由巢狀函數調用。因此，它返回 nil，從而使恐慌得不到處理。

這個關鍵差異凸顯了直接在延遲函數中使用 receive() 以確保 Golang 中有效的恐慌恢復的重要性。

以上是為什麼嵌套的'defer”無法恢復 Go 中的恐慌？的詳細內容。更多資訊請關注PHP中文網其他相關文章！