Bir süredir bu konuyu düşünüyorum ve diğer geliştiricilerin görüşlerini almak isterdim.
Çok savunmacı bir programlama tarzım var. Benim tipik blok veya yöntem şöyle görünür:
T foo(par1, par2, par3, ...)
{
// Check that all parameters are correct, return undefined (null)
// or throw exception if this is not the case.
// Compute and (possibly) return result.
}
Ayrıca, hesaplama sırasında, tüm işaretçileri silmeden önce kontrol ediyorum. Benim fikrim, eğer bir hata varsa ve bir yerde NULL işaretçisi görünmesi gerekiyorsa, programım bu güzel işlemeli ve sadece hesaplamaya devam etmeyi reddetmelidir. Tabii ki günlükte bir hata mesajı veya başka bir mekanizma ile sorunu bildirebilir.
Daha soyut bir şekilde ifade etmek gerekirse, yaklaşımım
if all input is OK --> compute result
else --> do not compute result, notify problem
Diğer geliştiriciler, aralarında bazı meslektaşlarım başka bir strateji kullanıyorlar. Örneğin, işaretçileri kontrol etmezler. Bir kod parçasına doğru girdi verilmesi gerektiğini ve girdinin yanlış olması durumunda olanlardan sorumlu olmaması gerektiğini varsayarlar. Ayrıca, bir NULL işaretçi istisnası programı çökerse, hata sırasında test sırasında daha kolay bir hata bulunacak ve düzeltilme şansı daha fazla olacaktır.
Buna cevabım normalde: ancak test sırasında hata bulunmazsa ve ürün müşteri tarafından zaten kullanılıyorsa görünürse ne olur? Hatanın kendini göstermesi için tercih edilen bir yol nedir? Belirli bir eylemi gerçekleştirmeyen, ancak yine de çalışmaya devam edebilen bir program mı yoksa çöküp yeniden başlatılması gereken bir program mı olmalı?
Özetleme
Yanlış girdiyi ele almak için iki yaklaşımdan hangisini önerirsiniz?
Inconsistent input --> no action + notification
veya
Inconsistent input --> undefined behaviour or crash
Düzenle
Cevap ve önerileriniz için teşekkürler. Ben de sözleşme ile tasarım hayranıyım. Ama benim yöntemleri (belki de kendim) çağıran kodu yazdı kişiye güven bile, yine de yanlış giriş yol açan, hatalar olabilir. Bu yüzden yaklaşımım asla bir yöntemin doğru girdiden geçtiğini varsaymamaktır.
Ayrıca, sorunu yakalamak ve bunu bildirmek için bir mekanizma kullanırdım. Bir geliştirme sisteminde, kullanıcıyı bilgilendirmek için bir iletişim kutusu açılır. Bir üretim sisteminde sadece günlüğe bazı bilgiler yazacaktır. Fazladan kontrollerin performans sorunlarına yol açabileceğini düşünmüyorum. İddiaların yeterli olup olmadığından emin değilim, eğer bir üretim sisteminde kapatılmışlarsa: belki üretim sırasında test sırasında meydana gelmemiş bir durum ortaya çıkacaktır.
Her neyse, birçok kişinin zıt yaklaşımı izlemesine gerçekten şaşırdım: uygulamanın "bilerek" çökmesine izin verdiler, çünkü bunun test sırasında hata bulmayı kolaylaştıracağını savunuyorlar.