Menyingkap Sebab di sebalik Pemulihan Tidak Berkesan dalam Fungsi Tertunda Bersarang
Di Golang, recover() berfungsi sebagai mekanisme penting untuk mengendalikan pengecualian dan mencegah penyebaran panik. Walau bagaimanapun, pemerhatian yang menarik timbul apabila menggunakan recover() dalam fungsi tertunda bersarang. Bertentangan dengan jangkaan, panik mungkin masih berlaku walaupun terdapat penangguhan bersarang.
Untuk menggambarkan anomali ini, pertimbangkan kod berikut:
package main import "fmt" func printRecover() { r := recover() fmt.Println("Recovered:", r) } func main() { // Direct deferred call to recover() defer printRecover() panic("OMG!") }
Apabila dilaksanakan, kod ini beroperasi seperti yang dimaksudkan:
Recovered: OMG!
Walau bagaimanapun, apabila kami menyertakan printRecover() dalam penangguhan bersarang fungsi:
package main import "fmt" func printRecover() { r := recover() fmt.Println("Recovered:", r) } func main() { // Nested deferred call to recover() defer func() { printRecover() }() panic("OMG!") }
Hasilnya berubah:
Recovered: <nil> panic: OMG! goroutine 1 [running]: main.main() /tmp/sandbox898315096/main.go:15 +0x60
Percanggahan berpunca daripada gelagat unik recover(). Mengikut spesifikasi Go, recover():
Mengembalikan sifar jika:
Dalam kes tertunda bersarang, recover() tidak digunakan secara langsung oleh fungsi tertunda paling luar tetapi oleh fungsi tertunda. Akibatnya, ia mengembalikan sifar, meninggalkan panik tidak dikendalikan.
Perbezaan penting ini menyerlahkan kepentingan menggunakan recover() secara langsung dalam fungsi tertunda untuk memastikan pemulihan panik yang berkesan di Golang.
Atas ialah kandungan terperinci Mengapa Nested `menangguhkan` Gagal Memulihkan Panik dalam Go?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!