Go Panic ve Recover: Çalışma Zamanı Panic'leri ve Ne Zaman Panic

Bir panic neye benzer

Bir panic mevcut fonksiyonu durdurur, ertelenmiş çağrılarını çalıştırır, sonra aynısını çağıranında yapar ve stack boyunca yukarı böyle devam eder. Goroutine'in en üstüne ulaşırsa program çöker.

package main

import "fmt"

func main() {
	defer fmt.Println("deferred in main: still runs")

	nums := []int{1, 2, 3}
	i := 5
	fmt.Println("before")
	fmt.Println(nums[i]) // panics
	fmt.Println("never printed")
}

Bu program 2 durumuyla çıkar. Çıktı:

before
deferred in main: still runs
panic: runtime error: index out of range [5] with length 3

goroutine 1 [running]:
main.main()
	/tmp/main.go:11 +0x...
exit status 2

Ertelenmiş çağrı çökme raporundan önce çalıştı. Trace goroutine'i, fonksiyonu ve satırı adlandırır; bu genellikle hatayı bulmak için yeterlidir.

Yaygın çalışma zamanı panic'leri

Bunların her biri programdaki bir bug'dır, ele alınacak bir durum değil. Çözüm bir recover değil; bir sınır kontrolü, bir nil kontrolü, bir make ya da virgül-ok assertion'ıdır.

Recover etmek

recover() bir panic'i durdurur. Yalnızca doğrudan ertelenmiş bir fonksiyonun içinde çağrıldığında çalışır, çünkü bir panic geri sarılırken çalışan tek kod ertelenmiş fonksiyonlardır.

package main

import "fmt"

func safeDivide(a, b int) (result int, err error) {
	defer func() {
		if r := recover(); r != nil {
			err = fmt.Errorf("recovered: %v", r)
		}
	}()
	return a / b, nil
}

func main() {
	fmt.Println(safeDivide(10, 2))
	fmt.Println(safeDivide(1, 0))
	fmt.Println("program continues")
}

Çıktı:

5 <nil>
0 recovered: runtime error: integer divide by zero
program continues

İkinci çağrıda olanlar:

1. a / b panic oldu.
2. Ertelenmiş closure çalıştı ve recover() panic değerini (bir runtime.Error) döndürdü.
3. Geri sarma durdu. safeDivide, closure'ın ayarladığı adlı sonuç err ile main'e normal biçimde döndü.

Ertelenmiş fonksiyonun bir hatayı geri vermesini sağlayan adlı sonuçtur. Adlı sonuç olmadan fonksiyon sıfır değerlerini döndürür. Ertelenmiş closure'ların sonuçları nasıl değiştirdiğini defer sayfası anlatıyor.

Panic olmadığında recover() nil döndürür, bu yüzden if r != nil kontrolü ertelenmiş fonksiyonu normal yolda zararsız yapar. Ertelenmiş bir fonksiyonun dışında ya da ertelenmiş fonksiyonun çağırdığı bir fonksiyonda çağrılırsa recover nil döndürür ve hiçbir şey yapmaz.

Kendi değerinizle panic

panic herhangi bir değer alır. Bir error ya da bir string tipiktir.

package main

import (
	"errors"
	"fmt"
)

var ErrInvariant = errors.New("invariant violated")

func mustPositive(n int) int {
	if n <= 0 {
		panic(fmt.Errorf("mustPositive(%d): %w", n, ErrInvariant))
	}
	return n
}

func main() {
	defer func() {
		r := recover()
		if err, ok := r.(error); ok && errors.Is(err, ErrInvariant) {
			fmt.Println("caught:", err)
			return
		}
		if r != nil {
			panic(r) // not ours: re-panic
		}
	}()

	fmt.Println(mustPositive(3))
	fmt.Println(mustPositive(-1))
}

Beklediğinizi recover edin, geri kalan her şey için yeniden panic yapın. Her panic'i yutmak gerçek bug'ları gizler.

Go 1.21'den beri panic(nil) bir *runtime.PanicNilError'a dönüştürülür, bu yüzden recover()'ın nil döndürmesi artık güvenilir biçimde "panic yok" anlamına gelir.

Goroutine'lerde panic'ler

recover yalnızca kendi goroutine'indeki panic'leri yakalar. Recover'ı olmayan herhangi bir goroutine'deki panic, main ve diğer tüm goroutine'ler dahil bütün süreci öldürür.

package main

import (
	"fmt"
	"sync"
)

func safeGo(wg *sync.WaitGroup, name string, f func()) {
	wg.Add(1)
	go func() {
		defer wg.Done()
		defer func() {
			if r := recover(); r != nil {
				fmt.Printf("worker %s panicked: %v\n", name, r)
			}
		}()
		f()
	}()
}

func main() {
	var wg sync.WaitGroup
	safeGo(&wg, "ok", func() { fmt.Println("worker ok done") })
	safeGo(&wg, "bad", func() {
		var m map[string]int
		m["x"] = 1
	})
	wg.Wait()
	fmt.Println("main finished")
}

İki worker satırı herhangi bir sırayla yazdırılabilir; main finished her zaman en son gelir. main içindeki bir defer recover() programı ikinci worker'dan kurtaramazdı. HTTP sunucularının istek başına recover etmesinin nedeni budur: net/http her handler goroutine'indeki panic'leri recover eder, loglar ve o bağlantıyı kapatır; böylece tek bir hatalı istek sunucuyu çökertmez.

Bazı başarısızlıklar panic değil ölümcül hatadır ve hiç recover edilemez: concurrent map writes, belleğin tükenmesi ve deadlock dedektörünün all goroutines are asleep mesajı.

Panic ne zaman doğru seçimdir

Go'nun genel kuralı: çalışma zamanında ters gidebilecek her şey için hata döndürün, yalnızca programcı hataları için panic yapın. Somut olarak panic şu durumlarda uygundur:

• Bir değişmez bozulduğunda. Kendi enum'unuz üzerindeki bir switch, olamayacak bir case'e ulaşır. Devam etmek veriyi bozar.
• Bir Must yardımcısı hatalı sabit girdi aldığında. regexp.MustCompile, template.Must ve uuid.MustParse hata döndüren bir fonksiyonu sarar ve başarısızlıkta panic yapar. Bunları derleme zamanında bilinen değerler için, genellikle başarısızlığın kaynak kodun yanlış olduğu anlamına geldiği paket seviyesi değişkenler için kullanın:

var emailRE = regexp.MustCompile(`^[^@\s]+@[^@\s]+$`)

• Başlangıç devam edemediğinde. main içinde eksik zorunlu yapılandırma. Burada bile hatayı yazdırıp os.Exit(1) çağırmak çoğu zaman bir stack trace'ten daha temizdir.

Panic şunlar için yanlış araçtır:

• Beklenen başarısızlıklar: geçersiz kullanıcı girdisi, eksik bir dosya, bir timeout. Bir error döndürün; bkz. hata yönetimi.
• Kontrol akışı: panic ve recover'ı büyük bir çağrı ağacında exception gibi kullanmak kodu takip edilmesi zor hale getirir. Standart kütüphane bunu kendi içinde birkaç yerde yapar (encoding/json encoder'ı), ama dönmeden önce her zaman recover eder, böylece hiçbir panic paketten dışarı kaçmaz.
• Kütüphane API'leri: hatalı girdide panic yapan bir kütüphane her çağıranı recover eklemeye zorlar. Bir hata döndürün.

Sık yapılan hatalar

• recover'ı ertelenmiş bir fonksiyonun dışında çağırmak. nil döndürür.
• Bir goroutine'in panic'i için main içinde recover etmek. Her goroutine'in kendi recover'ı gerekir.
• Tüm panic'leri yutmak. Stack ile birlikte loglayın (runtime/debug'daki debug.Stack()) ve beklemediğiniz şeyler için yeniden panic yapın.
• Nil map yazmalarını ya da aralık dışı indeksleri ele almak için recover kullanmak. Bunun yerine bug'ı düzeltin.