在 defer 函數內部發生恐慌是否可以，特別是當它已經發生恐慌時？

在defer函數內部發生恐慌時，是否會產生影響？這是一個常見的問題，尤其是在已經發生恐慌的情況下。在PHP中，defer函數用於在當前函數返回之前執行一些清理操作。當發生恐慌時，程式會立即停止執行，並且所有的defer函數都會按照後進先出的順序執行。因此，即使在發生恐慌之後，defer函數仍然會被執行。這對於處理資源釋放和錯誤處理等任務非常有用。無論發生了什麼，defer函數始終可靠地執行，確保程式碼的完整性和穩定性。

問題內容

func sub(){
    defer func (){
        panic(2)
    }()
    panic(1)
}

func main(){
    defer func(){
        x:=recover()
        println(x.(int));
    }()
    sub()
}

我嘗試了這段程式碼，似乎第一個恐慌 panic(1) 被第二個恐慌 panic(2) 「覆蓋」。

但是這樣做可以嗎？或者呼叫可能會在 defer 函數內發生恐慌的 Golang 函數？

（在C 中，從析構函數中拋出異常幾乎是不可接受的。如果堆疊已經展開，它會終止程式。我想知道以類似方式發生恐慌在Golang 中是否會很糟糕。）

解決方法

是的，沒關係。延遲函數引起的恐慌並不是真正的新的特殊狀態，它只是意味著恐慌序列不會停止。

您的範例程式碼也證明了它沒問題，甚至panic() 稱為可以透過對recover()的“上”級呼叫來停止延遲函數。

規格：處理恐慌：

#

這裡需要注意的一件事是，即使您在延遲函數中呼叫 panic()，所有其他延遲函數仍然會運行。另外，來自延遲函數的沒有recover() 的panic() 寧願「包裝」現有的恐慌，而不是「覆蓋」它（儘管recover() 呼叫確實只會傳回傳遞給最後一次panic() 呼叫）。

請參閱此範例：

func main() {
    defer func() {
        fmt.Println("Checkpoint 1")
        panic(1)
    }()
    defer func() {
        fmt.Println("Checkpoint 2")
        panic(2)
    }()
    panic(999)
}

輸出（在 Go Playground 上嘗試）：

c2e572c1c34a0369ef7​​989373914f540

即使所有延遲函數都呼叫 panic()，所有延遲函數都會執行，並且列印的最終恐慌序列包含傳遞給所有 panic() 呼叫的值。

如果您在延遲函數中呼叫 recover()，您也會在最終列印輸出中獲得此「已復原」狀態或資訊：

defer func() {
    recover()
    fmt.Println("Checkpoint 1")
    panic(1)
}()
defer func() {
    recover()
    fmt.Println("Checkpoint 2")
    panic(2)
}()

輸出（在 Go Playground 上嘗試）：

Checkpoint 2
Checkpoint 1
panic: 999 [recovered]
    panic: 2 [recovered]
    panic: 1
...

以上是在 defer 函數內部發生恐慌是否可以，特別是當它已經發生恐慌時？的詳細內容。更多資訊請關注PHP中文網其他相關文章！