İddiaları veya istisnaları kullanarak sözleşmeye göre tasarım mı yapıyorsunuz? [kapalı]

Sözleşmeyle programlama yaparken, bir işlev veya yöntem, sorumlulukları üzerinde çalışmaya başlamadan önce ilk olarak ön koşullarının yerine getirilip getirilmediğini kontrol eder, değil mi? Bu kontrolleri yapmanın en belirgin iki yolu assertara ara exception.

1. assert yalnızca hata ayıklama modunda başarısız olur. Gerçekten başarısız olup olmadıklarını görmek için tüm ayrı sözleşme ön koşullarını test etmenin (birim) çok önemli olduğundan emin olmak için.
2. istisna, hata ayıklama ve yayın modunda başarısız olur. Bu, test edilen hata ayıklama davranışının sürüm davranışıyla aynı olması avantajına sahiptir, ancak çalışma zamanı performans cezasına neden olur.

Sizce hangisi tercih edilir?

İlgili soruya buradan bakın

Yayın derlemelerinde iddia etmeyi devre dışı bırakmak, "Bir sürüm yapısında hiçbir zaman sorun yaşamayacağım" demek gibidir, ki bu genellikle böyle değildir. Bu nedenle, bir sürüm yapısında assert devre dışı bırakılmamalıdır. Ancak, hata oluştuğunda sürüm yapısının da çökmesini istemezsiniz, değil mi?

Bu yüzden istisnaları kullanın ve bunları iyi kullanın. İyi, sağlam bir istisna hiyerarşisi kullanın ve yakaladığınızdan ve onu yakalamak için hata ayıklayıcınızda istisna atmaya bir kanca koyabildiğinizden emin olun ve serbest bırakma modunda düz bir çökme yerine hatayı telafi edebilirsiniz. Gitmenin daha güvenli yolu.

Temel kural, kendi hatalarınızı yakalamaya çalışırken iddiaları ve diğer insanların hatalarını yakalamaya çalışırken istisnaları kullanmanız gerektiğidir. Başka bir deyişle, genel API işlevlerinin ön koşullarını ve sisteminizin dışında olan herhangi bir veriyi aldığınızda kontrol etmek için istisnaları kullanmalısınız. Sisteminize dahil olan işlevler veya veriler için istemler kullanmalısınız.

İzlediğim ilke şudur: Bir durum kodlama ile gerçekçi bir şekilde önlenebiliyorsa, o zaman bir iddia kullanın. Aksi takdirde bir istisna kullanın.

İddialar, Sözleşmeye uyulmasını sağlamak içindir. Sözleşmenin adil olması gerekir, böylece müşterinin uygun olmasını sağlayacak bir konumda olması gerekir. Örneğin, bir URL'nin geçerli olması gerektiğini, çünkü geçerli bir URL'nin ne olduğu ve ne olmadığına ilişkin kurallar bilindiği ve tutarlı olduğu için bir sözleşmede belirtebilirsiniz.

İstisnalar, hem istemcinin hem de sunucunun kontrolü dışındaki durumlar içindir. Bir istisna, bir şeyin ters gittiği ve bundan kaçınmak için yapılabilecek hiçbir şey olmadığı anlamına gelir. Örneğin, ağ bağlantısı uygulama kontrolünün dışındadır, dolayısıyla bir ağ hatasını önlemek için yapılabilecek hiçbir şey yoktur.

İddia / İstisna ayrımının bunu düşünmenin en iyi yolu olmadığını eklemek isterim. Gerçekten düşünmek istediğiniz şey, sözleşme ve nasıl uygulanabileceğidir. Yukarıdaki URL örneğimde, yapılacak en iyi şey, bir URL'yi kapsülleyen ve Null veya geçerli bir URL olan bir sınıfa sahip olmaktır. Sözleşmeyi zorunlu kılan bir dizenin URL'ye dönüştürülmesidir ve geçersizse bir istisna atılır. URL parametresine sahip bir yöntem, String parametresi olan bir yöntemden ve bir URL'yi belirten bir onaylamadan çok daha açıktır.

İddialar, bir geliştiricinin yanlış yaptığı bir şeyi yakalamak içindir (sadece kendiniz değil, ekibinizdeki başka bir geliştirici de). Bir kullanıcı hatasının bu durumu yaratması makul ise, bu bir istisna olmalıdır.

Aynı şekilde sonuçları da düşünün. Bir iddia genellikle uygulamayı kapatır. Durumun düzeltilebileceğine dair gerçekçi bir beklenti varsa, muhtemelen bir istisna kullanmalısınız.

Öte yandan, sorun yalnızca bir programcı hatasından kaynaklanıyorsa, o zaman bir assert kullanın, çünkü bunu mümkün olan en kısa sürede öğrenmek istiyorsunuz. Bir istisna yakalanabilir ve halledilebilir ve bunu asla öğrenemezsiniz. Ve evet, sürüm kodundaki iddiaları devre dışı bırakmalısınız çünkü orada olabilecek en ufak bir şans varsa uygulamanın kurtarılmasını istersiniz. Programınızın durumu derinden bozulmuş olsa bile, kullanıcı işini kurtarabilir.

"Assert'in yalnızca hata ayıklama modunda başarısız olduğu" tam olarak doğru değildir.

Gelen Yazılım İnşaat, 2nd Edition nesne yönelimli Bertrand Meyer, sürüm modunda ön şartlarını kontrol için açık yazar yaprakları bir kapı ile. Bu durumda, bir iddia başarısız olduğunda olan şey şudur ... bir iddia ihlali istisnası ortaya çıkar! Bu durumda, durumdan herhangi bir kurtarma yoktur: yine de faydalı bir şey yapılabilir ve bu, otomatik olarak bir hata raporu oluşturmak ve bazı durumlarda uygulamayı yeniden başlatmaktır.

Bunun arkasındaki motivasyon, ön koşulların tipik olarak test edilmesinin değişmezler ve son koşullara göre daha ucuz olması ve bazı durumlarda sürüm yapısındaki doğruluk ve "güvenliğin" hızdan daha önemli olmasıdır. Örneğin, birçok uygulama için hız bir sorun değil, sağlamlıktır (programın davranışı doğru olmadığında, yani bir sözleşme bozulduğunda, güvenli bir şekilde davranma yeteneği).

Ön koşul kontrollerini her zaman etkin bırakmalı mısınız? Değişir. Sana kalmış. Evrensel bir cevap yok. Bir banka için yazılım yapıyorsanız, yürütmeyi endişe verici bir mesajla kesmek, 1.000 $ yerine 1.000.000 $ transfer etmekten daha iyi olabilir. Peki ya bir oyun programlıyorsanız? Belki de alabileceğiniz tüm hıza ihtiyacınız vardır ve ön koşulların yakalayamadığı bir hata nedeniyle (çünkü etkinleştirilmedikleri için) biri 10 yerine 1000 puan alırsa, şanssızlık.

Her iki durumda da ideal olarak test sırasında bu hatayı yakalamış olmanız ve testinizin önemli bir bölümünü iddialar etkinken yapmanız gerekir. Burada tartışılan, eksik test nedeniyle daha önce tespit edilemeyen bir senaryoda üretim kodunda ön koşulların başarısız olduğu nadir durumlar için en iyi politika nedir.

Özetlemek gerekirse, en azından Eiffel'de , iddialarınız olabilir ve istisnaları etkin bırakırsanız otomatik olarak yine de alabilirsiniz . Sanırım aynısını C ++ 'da yapmak için kendiniz yazmanız gerekiyor.

Ayrıca bakınız: İddialar ne zaman üretim kodunda kalmalıdır?

Comp.lang.c ++. Moderated üzerindeki sürüm yapılarında iddiaların etkinleştirilmesi / devre dışı bırakılmasıyla ilgili büyük bir konu vardı , eğer birkaç haftanız varsa bu konudaki fikirlerin ne kadar farklı olduğunu görebilirsiniz. :)

Coppro'nun aksine , bir yayın yapısında bir iddianın devre dışı bırakılabileceğinden emin değilseniz, bunun bir iddia olmaması gerektiğine inanıyorum. İddialar, program değişmezlerinin bozulmasına karşı koruma sağlamaktır. Böyle bir durumda, kodunuzun müşterisi söz konusu olduğunda, iki olası sonuçtan biri olacaktır:

1. Bir tür işletim sistemi tipi arızayla ölün ve iptal çağrısıyla sonuçlanır. (İddia etmeden)
2. Doğrudan iptal çağrısıyla ölün. (İddia ile)

Kullanıcı için bir fark yoktur, ancak, iddiaların, kodun başarısız olmadığı çalıştırmaların büyük çoğunluğunda bulunan kodda gereksiz bir performans maliyeti eklemesi mümkündür.

Sorunun cevabı aslında daha çok API istemcilerinin kim olacağına bağlı. API sağlayan bir kitaplık yazıyorsanız, müşterilerinize API'yi yanlış kullandıklarını bildirmek için bir tür mekanizmaya ihtiyacınız vardır. Kitaplığın iki versiyonunu sağlamazsanız (biri iddia içeren, diğeri olmayan) o zaman uygun seçimin iddia etme olasılığı çok düşüktür.

Ancak kişisel olarak, bu dava için de istisnalarla gideceğimden emin değilim. İstisnalar, uygun bir kurtarma biçiminin gerçekleşebileceği yerlere daha uygundur. Örneğin, bellek ayırmaya çalışıyor olabilirsiniz. Bir 'std :: bad_alloc' istisnası yakaladığınızda, hafızayı boşaltmak ve yeniden denemek mümkün olabilir.

Konunun durumuna ilişkin görüşümü burada özetledim: Bir nesnenin iç durumunu nasıl doğrularsınız? . Genel olarak, iddialarınızı ileri sürün ve başkaları tarafından ihlal edildiğini iddia edin. Sürüm yapılarında onayları devre dışı bırakmak için şunları yapabilirsiniz:

• Pahalı kontroller için iddiaları devre dışı bırakın (bir aralığın sipariş edilip edilmediğini kontrol etmek gibi)
• Önemsiz kontrolleri etkin tutun (boş gösterici veya boole değeri kontrol etme gibi)

Elbette, sürüm yapılarında, başarısız iddialar ve yakalanmamış istisnalar, hata ayıklama yapılarında (std :: abort çağırabilir) başka bir şekilde ele alınmalıdır. Bir yere (muhtemelen bir dosyaya) hatanın günlüğünü yazın, müşteriye dahili bir hata oluştuğunu söyleyin. Müşteri size günlük dosyasını gönderebilecektir.

tasarım zamanı ve çalışma zamanı hataları arasındaki farkı soruyorsunuz.

'hey programcı, bu bozuk' bildirimleridir, bunlar gerçekleştiğinde fark etmeyeceğiniz hataları size hatırlatmak için oradalar.

istisnalar, 'hey kullanıcı, bazı şeyler ters gitti' bildirimleridir (açıkça onları yakalamak için kodlayabilirsiniz, böylece kullanıcıya asla haber verilmez) ancak bunlar, Joe kullanıcısı uygulamayı kullanırken çalışma zamanında gerçekleşecek şekilde tasarlanmıştır.

Bu nedenle, tüm hatalarınızı giderebileceğinizi düşünüyorsanız, yalnızca istisnaları kullanın. Yapamayacağınızı düşünüyorsanız ..... istisnaları kullanın. Elbette istisna sayısını azaltmak için hata ayıklama iddialarını kullanabilirsiniz.

Ön koşulların çoğunun kullanıcı tarafından sağlanan veriler olacağını unutmayın, bu nedenle kullanıcıya verilerinin işe yaramadığını bildirmenin iyi bir yoluna ihtiyacınız olacak. Bunu yapmak için, genellikle hata verilerini çağrı yığınından, etkileşimde olduğu bitlere döndürmeniz gerekir. İddialar o zaman yararlı olmayacaktır - uygulamanız n katmanlı ise iki katına çıkar.

Son olarak, her ikisini de kullanmazdım - hata kodları, düzenli olarak meydana geleceğini düşündüğünüz hatalardan çok daha üstündür. :)

İkincisini tercih ederim. Testleriniz iyi gitmiş olsa da Murphy beklenmedik bir şeyin ters gideceğini söylüyor. Bu nedenle, gerçek hatalı yöntem çağrısında bir istisna elde etmek yerine, bir NullPointerException (veya eşdeğer) 10 yığın çerçevesi daha derin izlersiniz.

Önceki cevaplar doğrudur: genel API işlevleri için istisnalar kullanın. Bu kuralı esnetmek isteyebileceğiniz tek zaman, kontrolün hesaplama açısından pahalı olduğu zamandır. Bu durumda sen olabilir bir assert koydu.

Bu ön koşulu ihlal etme ihtimalinin yüksek olduğunu düşünüyorsanız, bunu bir istisna olarak tutun veya ön koşulu yeniden düzenleyin.

İkisini de kullanmalısın. İddialar, bir geliştirici olarak size kolaylık sağlamak içindir. İstisnalar, çalışma süresi boyunca kaçırdığınız veya beklemediğiniz şeyleri yakalar.

Ben düşkün büyüdüğümüz glib hatası raporlama fonksiyonları yerine eski düz iddia ait. Assert ifadeleri gibi davranırlar, ancak programı durdurmak yerine bir değer döndürürler ve programın devam etmesine izin verirler. Şaşırtıcı derecede iyi çalışıyor ve bir bonus olarak, bir işlev "olması gerekeni" döndürmediğinde programınızın geri kalanına ne olacağını görüyorsunuz. Kilitlenirse, hata kontrolünüzün yolun başka bir yerinde gevşek olduğunu bilirsiniz.

Son projemde, ön koşul denetimini uygulamak için bu tarz işlevler kullandım ve bunlardan biri başarısız olursa, günlük dosyasına bir yığın izi yazdırır, ancak çalışmaya devam ederdim. Diğer insanlar benim hata ayıklama yapımı çalıştırırken bir sorunla karşılaştıklarında bana tonlarca hata ayıklama zamanı kazandırdı.

#ifdef DEBUG
#define RETURN_IF_FAIL(expr)      do {                      \
 if (!(expr))                                           \
 {                                                      \
     fprintf(stderr,                                        \
        "file %s: line %d (%s): precondition `%s' failed.", \
        __FILE__,                                           \
        __LINE__,                                           \
        __PRETTY_FUNCTION__,                                \
        #expr);                                             \
     ::print_stack_trace(2);                                \
     return;                                                \
 };               } while(0)
#define RETURN_VAL_IF_FAIL(expr, val)  do {                         \
 if (!(expr))                                                   \
 {                                                              \
    fprintf(stderr,                                             \
        "file %s: line %d (%s): precondition `%s' failed.",     \
        __FILE__,                                               \
        __LINE__,                                               \
        __PRETTY_FUNCTION__,                                    \
        #expr);                                                 \
     ::print_stack_trace(2);                                    \
     return val;                                                \
 };               } while(0)
#else
#define RETURN_IF_FAIL(expr)
#define RETURN_VAL_IF_FAIL(expr, val)
#endif

Bağımsız değişkenlerin çalışma zamanı kontrolüne ihtiyacım olsaydı, şunu yapardım:

char *doSomething(char *ptr)
{
    RETURN_VAL_IF_FAIL(ptr != NULL, NULL);  // same as assert(ptr != NULL), but returns NULL if it fails.
                                            // Goes away when debug off.

    if( ptr != NULL )
    {
       ...
    }

    return ptr;
}

Burada diğer cevaplardan birkaçını kendi görüşlerimle sentezlemeyi denedim.

Üretimde devre dışı bırakmak istediğiniz durumlarda iddiaları kullanın, onları içeride bırakmaya doğru ilerleyin. Üretimde devre dışı bırakmanın tek gerçek nedeni, ancak geliştirme aşamasında programı hızlandırmaktır. Çoğu durumda, bu hız önemli olmayacaktır, ancak bazen kod zaman açısından kritiktir veya test hesaplama açısından pahalıdır. Kod görev açısından kritikse, yavaşlamaya rağmen istisnalar en iyisi olabilir.

Gerçek bir kurtarma şansı varsa, iddialar kurtarılmak üzere tasarlanmadığından bir istisna kullanın. Örneğin, kod nadiren programlama hatalarından kurtulmak için tasarlanmıştır, ancak ağ hataları veya kilitli dosyalar gibi faktörlerden kurtulmak için tasarlanmıştır. Hatalar, sadece programcının kontrolü dışında oldukları için istisna olarak ele alınmamalıdır. Daha ziyade, kodlama hatalarına kıyasla bu hataların tahmin edilebilirliği, onları kurtarmaya daha uygun hale getirir.

İddialarda hata ayıklamanın daha kolay olduğu argümanı: Uygun şekilde adlandırılmış bir istisnadan gelen yığın izini okumak, bir iddia kadar kolaydır. İyi kod yalnızca belirli istisna türlerini yakalamalıdır, bu nedenle istisnalar yakalandıkları için fark edilmemelidir. Bununla birlikte, Java'nın bazen sizi tüm istisnaları yakalamaya zorladığını düşünüyorum.

Benim için temel kural, dahili hataları ve harici hatalar için istisnaları bulmak için assert ifadelerini kullanmaktır. Buradan Greg'in aşağıdaki tartışmasından çok yararlanabilirsiniz .

Onay ifadeleri, programlama hatalarını bulmak için kullanılır: ya programın mantığındaki hatalar ya da karşılık gelen uygulamasındaki hatalar. Bir onay koşulu, programın tanımlanmış durumda kaldığını doğrular. "Tanımlanmış bir durum" temelde programın varsayımlarına uyan bir durumdur. Bir program için "tanımlanmış durum" un "ideal durum" veya hatta "olağan bir durum" veya hatta "yararlı bir durum" olması gerekmediğini, ancak daha sonra bu önemli noktada daha fazla olması gerektiğini unutmayın.

İddiaların bir programa nasıl uyduğunu anlamak için, bir C ++ programında bir işaretçiye başvurmak üzere olan bir rutini düşünün. Şimdi rutin, göstericinin başvurudan önce NULL olup olmadığını sınamalı mı, yoksa göstericinin NULL olmadığını iddia etmeli ve sonra devam edip ondan bağımsız olarak vazgeçmeli mi?

Çoğu geliştiricinin, iddia edilen koşulun başarısız olması durumunda çökmemek için ikisini birden yapmak, assert eklemek, aynı zamanda işaretçide bir NULL değeri için kontrol etmek isteyeceğini hayal ediyorum. Yüzeyde, hem testi hem de kontrolü yapmak en akıllıca karar gibi görünebilir.

İddia edilen koşullarının aksine, bir programın hata işleme (istisnalar) programdaki hatalara değil, programın ortamından elde ettiği girdilere atıfta bulunur. Bunlar genellikle bir kullanıcının bir hesaba parola girmeden oturum açmaya çalışması gibi "hatalardır". Ve hata programın görevinin başarıyla tamamlanmasını engelleyebilse bile, program hatası yoktur. Program, kullanıcı tarafında bir hata olan harici bir hata nedeniyle şifre olmadan kullanıcı oturumunu açamıyor. Koşullar farklıysa ve kullanıcı doğru parolayı yazdıysa ve program bunu tanımıyorsa; o zaman sonuç hala aynı olsa da, başarısızlık artık programa ait olacaktır.

Hata işlemenin amacı (istisnalar) iki katlıdır. Birincisi, kullanıcıya (veya başka bir istemciye) programın girdisinde bir hatanın tespit edildiğini ve bunun ne anlama geldiğini bildirmektir. İkinci amaç, hata tespit edildikten sonra uygulamayı iyi tanımlanmış bir duruma geri yüklemektir. Bu durumda programın kendisinin hatalı olmadığına dikkat edin. Kabul edilirse, program ideal olmayan bir durumda, hatta yararlı hiçbir şey yapamayacak bir durumda olabilir, ancak programlama hatası yoktur. Aksine, hata kurtarma durumu programın tasarımı tarafından öngörüldüğünden, programın idare edebileceği durumdur.

Not: Benzer soruyu kontrol etmek isteyebilirsiniz: Exception Vs Assertion .

Ayrıca şu soruya bakın :

Bazı durumlarda, sürüm için oluştururken iddialar devre dışı bırakılır. Bunun üzerinde kontrole sahip olmayabilirsiniz (aksi takdirde, üzerinde iddialarla inşa edebilirsiniz), bu yüzden bunu böyle yapmak iyi bir fikir olabilir.

Girdi değerlerini "düzeltme" ile ilgili sorun, arayanın beklediğini alamamasıdır ve bu, programın tamamen farklı bölümlerinde sorunlara ve hatta çökmelere yol açarak hata ayıklamayı bir kabusa dönüştürür.

Devre dışı bırakılmaları durumunda iddia görevini üstlenmek için genellikle if ifadesine bir istisna koyarım

assert(value>0);
if(value<=0) throw new ArgumentOutOfRangeException("value");
//do stuff