Bunların ikisi de program hatası olarak algılanmalı. Kullanıcı hatalarının kullanıcıya temiz bir şekilde duyurulması daha doğru olur. Bunlar programın kendi hataları ile ilgili. Örneğin yazdığımız bir kütüphane işlevi yanlış bir şekilde çağrılıyordur.
Aslında ben de her durumda tam emin olamıyorum. Digital Mars forumunda 'enforce' başlıklı uzun bir konu var...
TDPL, Error sıradüzenine kesinlikle karışmamamız gerektiğini söylüyor. Onu, ikinci bir hata düzeneği gibi düşünebiliriz. Biz araya karışınca, derleyicinin oluşturduğu kodların işini bozabiliyormuşuz. Kural 1: O yüzden Error veya Throwable tutmayacağız.
Kesinlikle doğru olduğunu bildiğimiz koşulları assert ile denetleriz ya... İşte o denetim AssertError atar. Giderilemez bir durumdur, çünkü kesinlikle doğru olması beklenen bir koşulun yanlış olması, tanım gereği, yanlış bir urumdur... ;)
Bu noktada, std.contracts modülündeki 'enforce''u hatırlamak gerekiyor. TDPL de zaten onu öneriyor. enforce da assert gibi kullanılıyor, ama AssertError değil, Exception atıyor. O da programın doğruluğu ile ilgili ama Exception attığı için, onu yakalanması uygun olan durumlar için düşünüyoruz.
[Pes: Kitabı daha dün okuduğum halde ayrımını şimdi bile yapamıyorum. :)]
Bu ayrımın Java'da da olduğunu duymuştum. Giderilemez hatalar için Error; yakalanabilen, dolayısıyla hataya karşılık bir şeylerin yapılabildiği durumlar için Exception...
Şimdi dmd/src/phobos/std/ dizinindeki dosyalar içinde 'enforce' aratıyorum ve Andrei'nin onu hangi durumlara uygun bulduğunu anlamaya çalışıyorum. :D Örneğin 'reduce' işlevi, kendisine verilen aralığın boş olmamasını şart koşuyormuş. Bunu, 'enforce(!r.empty);' ile denetliyor. Ben de neredeyse "biz de kendi kodlarımızda hep enforce kullanmalıyız" diyeceğim ama tam da emin olamıyorum.
Ali
--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]