Go'da neden Try-Catch bulunmamaktadır?

Go, try-catch mekanizmasını kasıtlı olarak desteklememekte, yalnızca panic-recover sözdizimini desteklemektedir. Bu durum, try-catch kullanarak hata yönetimine alışkın sayısız geliştiricinin tepkisini çekmektedir. Peki, try-catch'in dahil edilmemesinin nedeni nedir? Bunun nedeni, try-catch'in çeşitli sorunlara sahip olmasıdır.

try-catch-finally

Try-catch ifadesi, program yürütmesi sırasında (runtime) meydana gelebilecek hata ve istisna durumlarını ele almak için kullanılan bir yapıdır. Ayrıca, finally ifadesi, bir istisna oluşup oluşmadığına bakılmaksızın mutlaka yürütülmesi gereken kodu içerir.

Hata Yönetimi ve Sorumluluk

1980'lerde ve 1990'larda hata yönetimi oldukça basitti. Hata mesajları 'Disket dolu', 'Sürücüde disket yok', 'Disket yazma izni yok' ibarelerinden ibaretti ve o dönemin geliştiricileri, bir hata meydana geldiğinde bu hatayı ortak bir noktada işlemek üzere hata işleme noktasına throw ederlerdi. Bu tür durumlarda try-catch ifadesi verimli bir şekilde çalışmaktaydı.

Ancak zamanla durum değişti. İş mantığı karmaşıklaştı, veritabanları ve Transaction'lar ortaya çıktı, ağ üzerinden sayısız API çağrılırken çok sayıda Request mesajının yorumlanması gerekti ve hatta eşzamanlı programlamanın ortaya çıkmasıyla ana iş parçacığı dışında başka iş parçacıklarında hataların ele alınması zorunlu hale geldi.

Hatalar, artık tek bir yerden ele alınamayacak kadar karmaşık hale geldi ve hiçbir yer tüm hatalardan sorumlu olamazdı. İşte bu noktada try-catch ciddi bir sorunla karşılaştı.

try-catch'in Sorumluluk Aktarımı

Try-catch, tek kelimeyle ifade etmek gerekirse, hatayı meydana getiren tarafın hata oluşumuna ilişkin sorumluluğu (sonraki işlemleri) başkasına devretme yöntemidir. Bu devredilen taraf, catch bloğu olabilir, kendi üst metodu olabilir veya kendi üst metodunun üst metodunun üst metodunun... bir başkası olabilir. Başka bir deyişle, hata yönetiminin arttığı ve karmaşıklaştığı bir dünyada, try-catch'in benimsediği yöntem, "Birisi halleder" düşüncesidir. Aşağıdaki koda bakalım.

1try {
2    data = readFile("hello.txt"); // hello.txt dosyasını oku
3    structuredData = parseData(data); // Veriyi ayrıştır
4    insertDBStatus(structuredData[1]); // Veritabanı durumunu ekle
5    startHTTPServer(structuredData[2]); // HTTP sunucusunu başlat
6} catch (Exception e) {
7    e.printStackTrace(); // Hata yığın izini yazdır
8}

Yukarıdaki kodun sorunu, printStackTrace'i işleyen tarafın kim olduğunun net olmaması ve hangi kodda hata oluştuğunun anlaşılamamasıdır. Hatta try ifadesi içinde daha fazla mantık oluştuğunda sorun daha da korkunç hale gelir. Ancak paradoksal olarak, geliştirme ne kadar karmaşıklaşırsa, geliştiriciler sorumluluğu devreden try-catch ifadelerine o kadar bağımlı hale geldi ve hata yönetimi hakkında düşünmeyi bıraktılar, sorumluluk duyguları da azaldı ve sonunda hata ve istisna yönetiminin özünü unuttular. Peki, Go bu sorunu nasıl çözdü?

panic, recover

Go'nun avantajlarından biri, geliştiricileri yanlış yollara düşürmeden iyi geliştiriciler olmaları için çeşitli sistemlere sahip olmasıdır. panic - recover da buna bir örnek olarak verilebilir.

Panic ve recover ilk bakışta try-catch'ten farklı görünmese de, bir sorun ortaya çıktığında sorumluluğu dışarıya atmamaları açısından farklıdırlar. Go'da bir panic meydana geldiğinde, bu değeri dışarıya aktarmak yerine panic'in meydana geldiği yerde çözülmesi gerekir. Bu, geliştiriciye hata yönetimi sorumluluğunu vererek, bu hatanın nerede, kim tarafından ve nasıl ele alınması gerektiği konusunda daha derinlemesine düşünmeye teşvik eder. Kullanıcıya özerklik sağlarken, düşünme alanı bırakır.

Ayrıca, "panic" kelimesinin seçimi de oldukça mükemmeldir; try-recover'dan farklı olarak panic-recover, kelimenin kendisiyle geliştiriciye, bu mekanizmanın istisnai durumlar için değil, açıkça hata durumlarında kullanılması gerektiği konusunda bir baskı uygular. Doğal olarak geliştirici, recover'ı kötüye kullanmaz ve yalnızca gerekli yerlerde kullanır. Bu, Go'da kısa ve öz kod yazmada büyük bir yardımcıdır.