Go, Java, C++, JavaScript ve Python gibi dillere kıyasla hatalar konusunda nispeten farklı bir anlayışa dayanır: Go'da hata, yerleşik error türünün bir değeridir ve işlev bunu genellikle diğer dönüş değerleriyle birlikte çağırana döndürür. Böylece hatayı incelemek ve ele almak, ayrı bir istisna mekanizmasına aktarılmak yerine program akışının görünür bir parçası hâline gelir.
Aslen topluluk katkıcısı Christoph Berger tarafından yazılan ve daha sonra JetBrains Go bloguna aktarılan JetBrains rehberi, giriş/çıkış, ağ, veri doğrulama ve diğer hatalarla ilgilenmek için çeşitli teknikler ve uygulamalar sunar. Rehber, Go dilindeki en güncel değişikliklere uyum sağlamak amacıyla Ağustos 2026'da güncellenmiştir.
Döndürme başlangıç noktasıdır
Bir işlevin sorunu ele almak için yeterli bağlamı yoksa hatayı çağıran işleve döndürmelidir. Go genellikle hata değerini dönüş listesinin sonuna yerleştirir; ReadFile() gibi bir işlev, dosya içeriğini ve başarı durumunda değeri nil, başarısızlık durumunda ise başka bir değer olan bir hatayı döndürür.
Rehber, çağıranın hatayı görmezden gelmek yerine hemen sınaması gerektiğini açıklar. İşlev dosya veya ağ bağlantısı gibi bir kaynak açtıysa çıkışta temizlemek için defer kullanılmalıdır; ancak önce açma işleminin başarılı olduğu doğrulanmalıdır, çünkü geçersiz bir kaynağı kapatmaya çalışmak ek bir soruna yol açabilir.
Hata yapısını bozmadan bağlam eklemek
Bir hata, ele alınmadan veya günlüğe kaydedilmeden önce bir işlevler zincirinden geçebilir. Bu geçiş sırasında her işlev, başarısız olan işlem veya üzerinde çalıştığı yol gibi yararlı bilgiler ekleyebilir. Ancak hatayı err.Error() birleştirmesiyle metne dönüştürmek, hata zincirini ve türsel yapısını kaybettirir.
Doğru yaklaşım, hatayı özgün hatayı koruyarak sarmalamak için %w belirteciyle birlikte fmt.Errorf() kullanmaktır. Bu, daha sonra tek bir katmana erişmek için errors.Unwrap() kullanılmasını veya sarmalama zincirindeki belirli hataların sınanması için errors.Is() ve errors.As() kullanılmasını sağlar. Go 1.26, As() için tür açısından güvenli bir alternatif olarak genel errors.AsType() işlevini ekler; bu işlev eşleşen hatayı ve bir mantıksal değer döndürür ve derleyicinin eski yaklaşımla çalışma zamanında ortaya çıkabilecek tür hatalarını tespit etmesine olanak tanır.
Birden çok hata ve iptal edilmiş bağlam
Hatalar her zaman doğrusal bir zincir oluşturmaz. Örneğin bir dosya grubunu işlerken bazı işlemler başarılı olabilir, diğerleri ise başarısız olabilir. Go 1.20'den beri kullanılabilen standart errors.Join() paketi, başarılı biçimde işlenen içeriği koruyarak birden çok hatayı tek bir değerde toplar.
Rehber, errors.Unwrap() işlevinin tek bir değer döndürdüğüne ve bu nedenle birleştirilmiş bir hatayla çalışırken nil döndürdüğüne dikkat çeker. Birleştirilmiş hatalara erişmek için değerin Unwrap() []error sağlayan arayüzü uygulayıp uygulamadığı doğrulanmalıdır. Ayrıca Go 1.20'den beri, iptal işlemini özel bir nedene bağlamak için context.WithCancelCause() kullanılabilir; ardından bu neden, genel context.Canceled değeriyle yetinmek yerine context.Cause(ctx) aracılığıyla alınabilir.
panic ne zaman uygundur?
panic ve recover, hata denetiminin olağan alternatifi olmamalıdır. Kullanıcı girdilerinin geçersiz olması, dosyaların eksik olması veya ağ zaman aşımı gibi beklenen hatalar, olağan dönüş yolu üzerinden ele alınmalı ve döndürülmelidir.
Panic, sorunun beklenmedik olduğu ve anlamlı bir işlem bulunmadığı durumlarda, örneğin önceden doğrulanması gereken sabit bir düzenli ifadenin derlenememesinde uygundur. HTTP sunucularında uygulama, mümkün olan yerlerde mevcut isteğin işlenmesindeki çöküşün diğer istekleri etkilemesini önlemek için ertelenmiş bir işlev içinde recover() kullanabilir. Belleğin tükenmesi gibi durumlarda ise uygulamanın devam etmek için pratik bir seçeneği kalmayabilir.
Geliştiriciler için pratikte önemli olan nedir?
- Hataları yok saymayın: Hata değerini boş tanımlayıcıya atamak veya tek dönüş değerini düşürmek, sorunun tespitini geciktirebilir ve sonraki etkilerinin teşhisini zorlaştırabilir.
- Uygun yerde günlüğe kaydedin: İşlev hatayı ele almalı veya çağırana döndürmelidir. Rehber, kütüphanelerin kendiliğinden günlük kaydı oluşturmasını önermemektedir; çünkü kullanıcıları farklı günlükleri veya farklı çıktı hedeflerini tercih edebilir.
- Uygun türleri kullanın: Özel hata türleri ek bilgiler taşıyabilir; işlem, yol ve iç hatayı sağlayan fs.PathError da bunu yapar.
- Ağ hatalarını ayırt edin: net.OpError, bağlantı başarısızlığının niteliğini incelemeye olanak tanır ve geçici hata, yeniden denemeye veya üstel geri çekilme gibi bir strateji kullanmaya izin verebilir.
- Giriş ve çıkış işlemlerindeki bayt sayısından yararlanın: io.Reader arayüzü, hatayla birlikte işlenen bayt sayısını döndürür; bu da tüm verileri yeniden işlemek yerine işlemin sürdürülmesine yardımcı olabilir.
- io.EOF'a dikkat edin: Paket semantiğine göre bu değer, okuma akışının başarılı biçimde sona erdiğini gösterir; mutlaka sıradan bir hata olarak günlüğe kaydedilmesi gereken bir başarısızlık değildir.
- log.Fatal() işlevini düşünmeden kullanmayın: Bu işlev os.Exit() çağırır ve ertelenmiş işlevlerin atlanmasına neden olur; bu nedenle rehber, kullanımının sınırlandırılmasını veya main() işlevinde os.Exit() kullanılmasını önermektedir.
certi.news'un editoryal sonucu, hata akışının açıklığının yalnızca ayrıntılı bir yazım tarzı değil, program tasarımının bir parçası olduğudur. Düzenli sarmalama, uygun türler ve sorumlu günlük kaydı teşhisi uygulanabilir hâle getirirken panic'e, genel mesajlara veya hataları düşürmeye güvenmek geliştiricinin daha sonra ihtiyaç duyacağı bilgileri gizler. Pratik tercih hâlâ uygulamanın bağlamına bağlıdır: İstek sunucusu sınırlı bir kurtarmaya ihtiyaç duyabilirken kurtarılamayan bir hata sonlandırmayı ve yeniden başlatmayı gerektirebilir.