Golang 延遲函數可以在不終止恐慌序列的情況下觸發新的恐慌嗎？

延遲函數內部的恐慌是否可以接受，特別是在現有恐慌期間？

考慮以下程式碼片段：

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

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

執行此指令時程式碼中，似乎最初的panic(1)被第二個panic(2)取代。

是否允許以這種方式繼續，或呼叫可能在defer 函數中？

是的，這是可以接受的。 由 defer 函數引起的恐慌並不是一個新的或獨特的情況；它只是表明恐慌序列將繼續。

提供的範例程式碼示範了這種可接受性，並說明了即使從defer 函數呼叫的panic() 也可以透過對recover() 的「更高」等級呼叫來捕獲.

Golang 規範規定，如果在執行延遲函數期間發生恐慌，如果恢復函數在沒有捕獲它的情況下執行了恐慌（），恐慌序列將不會結束。

此外，即使在延遲函數中呼叫panic()，所有其他延遲函數也會被執行。然而，延遲函數中沒有恢復函數的panic()將「包裝」現有的panic，而不是「覆蓋」它。

例如，考慮以下程式碼：

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

輸出：

Checkpoint 2
Checkpoint 1
panic: 999
    panic: 2
    panic: 1

即使每個defer 函數都呼叫panic()，它們仍然會被執行，並且產生的panic序列顯示傳遞給每個panic()呼叫的值。

當延遲函數中呼叫recover()時，最終的列印輸出也會顯示此「恢復」資訊：

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

輸出：

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

以上是Golang 延遲函數可以在不終止恐慌序列的情況下觸發新的恐慌嗎？的詳細內容。更多資訊請關注PHP中文網其他相關文章！