Go'da Boş Dönüş mü Hata mı: Tasarım Seçimi ve Sonuçları

Go'da bir fonksiyonun başarısız olduğunu nasıl sinyal verirsin? Bu soru sadece stil değil, kod güvenliğini ve bakımını doğrudan etkileyen bir tasarım kararıdır.

Go'nun felsefesi açık: hataları sessizce yok sayma lüksün yok. Dilin kültürü, `if err!= nil` kontrol etmeyi zorunlu kılar, en azından derleyici seni uyarır. Ama bu kuralın içinde iki yol vardır: `nil` döndürmek ya da bir hata nesnesi.

Çoğu Go kütüphanesi, özellikle standart kütüphane, ikili dönüş modeline sadık kalır: sonuç ve hata. `file, err:= os.Open("data.txt")` örneğinde, dosya açılamazsa `file` nil, `err` dolu gelir. Bu model net ve tutarlıdır. Ancak bazı tasarımlar, örneğin JSON ayrıştırıcılar, boş değer döndürmeyi tercih eder. Neden?

Boş dönüş (nil slice, empty string, zero value) tercih edildiğinde, çağıran kod daha az verbose olur. Bir JSON ayrıştırıcısı `nil` slice döndürürse, döngü doğal olarak çalışmaz, ekstra kontrol gerekmez. Ama bu sessizlik tehlikeli. Başarısızlık nedeni belirsiz kalır: veri yok mu, format hatalı mı, bellekte problem mi? Hata ayıklama sırasında bu muğlaklık saatleri kaybettirir.

Hata nesnesi döndürmek daha fazla iş gerektirir: her çağrıda kontrol, hata mesajı okuma, stack trace takip etme. Ama bu "iş" aslında tasarımın sağlıklı olduğunun kanıtı. Go'nun `errors.Is()` ve `errors.As()` fonksiyonları (Go 1.13+), hataları kategorize etmeyi kolaylaştırır. Farklı hata türlerine farklı tepki verebilirsin.

Praktik tavsiye: eğer operasyon başarısız olabilir ve çağıran kodu bunu bilmesi gerekiyorsa, hata döndür. Boş dönüş yalnızca iki durumda makul: (1) boş sonuç kendisi geçerli bir durumdur (örneğin, arama sonucu bulunamadı), (2) başarısızlık imkansız ya da çok nadir ve çağıran kodu bunu başka şekilde tespit eder.

Go'da başarısızlık sinyalleri tasarımı, kütüphanenin ne kadar kullanılacağına bağlı değişir. Dahili araç mı, kamu API'si mi? Kamu API'si ise hata açık olmalı. Sessiz başarısızlık, başkasının kodunda saatlerini harcatan bir bug'a dönüşür.