首頁 > 後端開發 > Golang > 在 defer 函數內部發生恐慌是否可以,特別是當它已經發生恐慌時?

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

WBOY
發布: 2024-02-11 20:33:08
轉載
1002 人瀏覽過

在 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中文網其他相關文章!

來源:stackoverflow.com
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板