Hata Yakalama ve Iskalama Kültürü

Ağustos 20, 2009 by mucit · 1 Comment 

Mike Hodlow‘un başlığını Fight Club’tan esinlendiği  “Hata Yakalamanın İlk Kuralı: Hatayı Yakalama!” yazısı, programlamada bir “exception handling” yani Türkçesiyle “hata yakalama” kültürünün olduğunu ve programcı / yazılımcı etiketindeki kimselerin de bu kültüre mutlaka aşina olması gerektiğini bana tekrar hatırlattı.

Yıllar evvel bir programlama aracı anlatan kitapta hatalardan “istisna” olarak bahsedildiğini görmüş ve oldum olası bu kavramdan uzak durmuştum. İstisnalar hem kaideyi bozar hem keyfi kaçırırdı.

Ancak zaman içinde anladık ki bir programcının bilmesi gereken şey aslında her insanın bilmesi gereken şey. Hayatta hata yapmak, yapmamak kadar doğaldır. Bir programın akışında hatalar oluşması da oluşmaması kadar olağan. Ve bu hatalar, yani arızî durumlar her seferinde farklı sebeblerden ortaya çıkabilir. Bir hata, başka hatalardan silsile yoluyla gelmiş olabilir (“Bir exception var exception’dan içerü” prensibi).

Evet, hatalar ne kadar normal dediysek yazıyı bu şekilde bitirip gideceğimizi sanmayınız. Anormal olanı demeden gitmeyiz.

Anormal olan şey, hatayı hesaba katmamaktır veya hataya karşı lakayıt kalmaktır. Bir program kodu oluşabilecek arızî durumlar akılda tutularak yazılmalıdır. Yazılmamışsa bile geri dönüp refactor (adam) edilmelidir. Akılda tutulmuşsa bile formaliteden değil yerinde müdaheleler yapılmalıdır.

Hata yakalama ile ilgili şu altın prensipler, umarım programcı arkadaşlarımız için faydalı olacaktır.

  • Programda üç tip arıza oluşur: 1- Programlamadan (sizden!) doğan arıza, 2- İstemciden doğan arıza, 3- Kaynaklardan doğan arıza. Hangi tür olursa olsun, hepsinde program hataya karşı hazır olmalıdır.
    • Programlama hataları ölümcül hatalardır. Programınız çakılır, devam edemez. Bir bug‘ınız vardır; siz çözene kadar öyle duracaktır.
    • İstemciden doğan arızalar daha çok doğrulama şeklinde yorumlanır. Örneğin kullanıcının size girdiği sayı, alfanumerik karakterler içeriyorsa bir ihlal vardır. Veya gönderdiği bir XML dosyası elinizdeki şemaya göre valid değildir. Bu tip hataları hiçbir şekilde ıskalamamanız ve yakalamanız gerekir.
    • Kaynaklar, kullanıcı ile aranıza giren üçüncü şahıslardır. Örneğin bellek dolmuştur. Ya da diskte yer bitmiştir. Bu tür durumları da titizlikle yakalayıp, ayırd edip mantıklı mesajlarla (vmware’yi kapat, biraz divx sil gibi…) kullanıcıyı yönlendirmek lazımdır.
  • Genel Exception sınıfları yerine özelleşmiş Exception‘lar yakalanmalıdır. .NET için konuşursak, System.Exception denen hataların babası, sadece tek bir noktada ve global olarak yakalanmalıdır. Bu tek bir nokta, genelde proses sınırı ya da daha anlaşılır bir tabirle Meksika sınırıdır. Kodun hiçbir iç noktasındaki try/catch bu baba hatayı tutmamalıdır. Hiyerarşiye uyulmalıdır. Kimse hatadan anlamadıysa, en son noktada yakalanmalı, log’lanmalı ve mağrur bir şekilde kullanıcıya işlemin devam edemediği bildirilmelidir.
  • Herkesin bildiği kural: mantıksal akış için Exception’lara yaslanılmamalıdır. Bu yapılar “iş” amaçlı değildir.
  • Herkesin çok ihlal ettiği kural: Exception’ların StackTrace‘i yutulmamalıdır. Eğer catch’lerde yakalayıp “bu yoluna devam etsin” dediğiniz hatalar olur ise onları mutlaka “throw“  ile gönderiniz; eğer “throw new” ile gönderirseniz o zor bulunan, kimi zaman değerine paha biçilmeyen “Stack Trace” sıfırlanmış olacaktır. Özetle “throw new” çok dikkatle kullanılması gereken bir kalıptır. Stack Trace muhafaza edilmesi gereken değerli bir madendir.
  • OOP mevsimine aldanıp yeni nesil Exception tipleri icad etmek yerine sistemin sizin için sunduğu öntanımlı olanları kullanınız. .NET size genel ihtiyaçlar için birçok tip sunuyor.
  • Exception’lar CLR için pahalı ve ağır lokmalardır. O nedenle mümkün olduğunda onlara bulaşmadan adımlamak lazımdır. Bunu yapmanın en güzel yolu da pattern’lere yani kullanım kalıplarına başvurmaktır.
  • Dokümantasyon: Her işimizi belgeli yapmalıyız. .NET’in kod içindeki XML dokumantasyon şeması, Exception’ları yazmaya da imkan veriyor. Eğer düzgünce yazarsanız, kod dokumantasyonunda metodlarınız için “taş düşebilir, ayı çıkabilir” nevinden notlar görülecek. Hoş değil mi?
  • Montaj yasası gereği hiçbir şey işe yaramıyorsa övülen pratiklere bakılmalıdır.