Exception Handling: Try-Catch mi Result Pattern mi?

Bu sorunun cevabı basit değil. Çoğu yazı "result pattern modern, try-catch eski" diye genelleme yapar. Ama gerçek daha nüanslı.

Try-catch, kontrol akışını kesintiye uğratır. Bir exception fırlatıldığında stack unwinding başlar ve eğer catch bloğu yoksa program çöker. Bu davranış beklenmeyen hatalar için ideal. Veritabanı bağlantısı koptu, dosya sistemi erişilmez oldu, network timeout, bunlar çoğu zaman işiniz dışında olan şeylerdir. Try-catch bu tür olayları yakalar ve uygulamayı düşürmez.

Ayrıca try-catch dil düzeyinde desteklendiği için tüm kütüphaneler bunu anlar. Bir üçüncü parti API çağırıyorsanız, o zaten exception fırlatabilir. Bunu result pattern'e dönüştürmek gereksiz çalışmadır.

Result pattern (Go'daki (value, error), Rust'taki Result<T, E>, C#'taki Result<T>) başarı ve başarısızlığı açıkça modellersiniz. Hata sadece kodu oku diye beklentiye bırakılmaz; tip sistemi sizi hatırlatır.

En büyük avantajı: kontrol akışı kesintiye uğramaz. Bir fonksiyon hata döndürürse, siz o hatayı ele alıp devam edersiniz. Stack unwinding yok, performans cezası yok. İş mantığınızın parçası olan hatalar için mükemmeldir, geçersiz giriş, yetkilendirme başarısızlığı, veri validasyonu.

Çoğu proje her iki yöntemi birlikte kullanır. Bu, kodu zor kılar. Bir fonksiyon result döndürüyor, diğeri exception fırlatıyor. Çağıran kod hem .Match() yazmak hem de try-catch bloğu açmak zorunda kalır.

Bu karmaşayı çözmek için seçim yapmak lazım:

İş hatalarına result pattern kullan. Kullanıcı yanlış giriş yaptı, para yetmedi, e-posta zaten kayıtlı, bunlar beklenen senaryolardır. Result tipi bu durumları açıkça ifade eder ve çağıran kod zorunlu olarak ele alır.

Beklenmeyen hatalara try-catch kullan. Veritabanı çöktü, dosya sistem izni reddetti, bellek tükendi. Bu tür olaylar genellikle uygulamanın dışında olur ve try-catch bu durumlar için yapılmıştır.

Result pattern daha modern ve tip güvenli görünüyor, ama try-catch'in yerini tamamen almıyor. Eğer her şeyi result'a dönüştürmek için çaba harcıyorsanız, yanlış yoldasınız.

İyi bir kod tabanı her iki aracı da doğru yerde kullanır. İş mantığı hatalarını result ile model et, sistem hatalarını try-catch ile yakala. Bu şekilde hem okunabilir hem bakımı kolay bir kod yazarsınız.