Go'da standart yaklaşım, hataları error döndüren bir değer aracılığıyla işlemektir. Bu, her noktada hata oluştuğunda ne yapılacağını açıkça kontrol etmeyi sağlar. Panic, beklenmedik felaket durumlarını işlemek için bir mekanizmadır: en yakın defer noktasında yürütmeyi durdurur ve burada recover kullanılarak "kurtarılabilir". Ancak recover yalnızca defer içinde çalışır.
En iyi uygulamalar:
func safeDivide(a, b int) (int, error) { if b == 0 { return 0, errors.New("sıfıra bölme") } return a/b, nil } func mustDivide(a, b int) int { if b == 0 { panic("sıfıra bölme!") } return a/b }
Herhangi bir panik hatasını recover ile programın herhangi bir yerinde yakalamak mümkün mü?
Cevap: Hayır, recover yalnızca defer içinde çalışır ve yalnızca panic'in çağrıldığı aynı goroutine'de çalışır. Diğer durumlarda panik, bu (veya tüm) goroutine'lerin yürütmesini sonlandırır — bu sıklıkla beklenmedik bir durum olur.
Hikaye
REST API'de iş mantığında normal hataları işlemek için panic kullanıldı. Bu, uygulamanın beklenmedik bir şekilde çökmesine ve yanlış loglamalara yol açtı, çünkü recover her zaman doğru bir şekilde çalışmadı.
Hikaye
Ödeme işleme hizmetinde, tüm panikleri "yakalmak" için ana fonksiyonda defer + recover uygulanmıştı, ancak goroutine'leri unuttular — alt goroutine'lerde defer/recover olmadan uygulama "korkunç" hatalarla çöktü ve bazı işlemleri tutarsız bir durumda bıraktı.
Hikaye
Karmaşık yapıların ayrıştırıcısında hata döndürmeyi unuttular, bu nedenle panic ile değiştirdiler — bu, bakım ve test sürecini zorlaştırdı, detaylı loglama ve doğru UX sağlamak için hata işleme tamamen yeniden yazılmak zorunda kaldı.