İstisnalar atama istisnalarına karşı mı?

Genellikle bir işlev yazarken, bu tür hataları olabildiğince erken tespit etmek için girdilerin geçerli olduğundan emin olmak istiyorum (bunlara ön koşul denir). Bir önkoşul başarısız olduğunda, her zaman bir istisna fırlattım. Ancak bunun en iyi uygulama olup olmadığından ve iddiaların daha uygun olacağından şüphe duymaya başladım.

Öyleyse ne zaman yapmalıyım: bir iddia kullanmak ne zaman ve ne zaman bir istisna atmak uygun olur?

İddialar sadece yanlış olması mantıklı olarak imkansız olması gereken koşulları doğrulamak için kullanılmalıdır (okuma: sağlık kontrolleri). Bu koşullar yalnızca kendi kodunuz tarafından oluşturulan girişlere dayanmalıdır. Harici girişlere dayanan kontroller istisnalar kullanmalıdır.

Takip etme eğiliminde olduğum basit bir kural, özel fonksiyonların iddialarla ilgili argümanlarını doğrulamak ve kamu / korunan fonksiyonların istisnalarını kullanmaktır.

Programlama hatalarını bulmak için iddialar kullanılır. Tüm iddiaların kaldırıldığı zaman programlarınız da iyi çalışmalıdır.

İstisnalar, diğer yandan, program mükemmel olduğunda bile olabilecek durumlar içindir; donanım, ağ, kullanıcılar gibi dış etkenlerden kaynaklanırlar.

Tipik bir programlama uygulaması, üretim / sürüm oluşturmalardan gelen iddiaları derlemektir. İddialar yalnızca iç test sırasında varsayımların başarısızlığını yakalamak için yardımcı olacaktır. Dış kurumların davranışını üstlenmemelisiniz, bu nedenle ağdan veya kullanıcıdan gelen olayları iddia etmemelisiniz. Ayrıca, bir iddianın başarısız olması durumunda üretim yapılarına ilişkin kullanım kodunu yazmak iyi bir uygulamadır.

Örneğin, C

int printf(const char *fmt, ...)
{
  assert(fmt);  // may fail in debug build but not in production build
  if (!fmt) return -1; // handle gracefully in production build
  ...
}

İstisnaların üretim yapılarına inşa edilmesi amaçlanmıştır. İstisnaya alternatif, iddiaları değil hata döndürmektir.

Benim için iddiaların bir sorunu, Java’da varsayılan olarak devre dışı bırakılmış olmalarıdır.

Yıllarca katılımsız çalışan programın, hatalı verilerde (beklenmedik bir şekilde) veri bozulmasını önlemek için olabildiğince erken çökmesi gereken ilk başarısız stratejisini kullanıyoruz. Bunu kontrol için kullandığımız şeydir ve varsayımları kullanarak temelde aktif olmadıklarını riske atarız.