ProgramlamaBackend Geliştirici

Panic/recover ve standart hata işleme yöntemleri arasında ayrıntılı bir karşılaştırma yapın: farklar, en iyi uygulamalar, tuzaklar. Panic kullanmak ne zaman haklıdır?

Hintsage yapay zeka asistanı ile mülakatları geçin

Cevap.

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:

  • Normal durumlar ve beklenen hatalar (dosya yok, geçersiz istek) için hata kullanın.
  • Panic yalnızca çalışmaya devam etmenin imkansız olduğu kritik hatalar için kullanılmalıdır (örneğin, invarianta aykırılık, başlatma hatası).
  • Normal akış için panic kullanmayın (örneğin, veri doğrulaması için).
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 }

Kandırmaca soru.

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.

Konunun inceliklerini bilmediği için gerçek hataların örnekleri.


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ı.