İddia kötülük mü? [kapalı]

GoDil yaratıcıları yazma :

Go iddialarda bulunmaz. İnkar edilemeyecek kadar kullanışlılar, ancak deneyimlerimiz, programcıların uygun hata işleme ve raporlama hakkında düşünmekten kaçınmak için bunları bir koltuk değneği olarak kullanmalarıydı. Doğru hata işleme, sunucuların çökme yerine ölümcül olmayan hatalardan sonra çalışmaya devam ettiği anlamına gelir. Doğru hata raporlaması, hataların doğrudan ve noktaya geldiği anlamına gelir ve programcının büyük bir kilitlenme izini yorumlamasını önler. Kesin hatalar, programcı hataları gören kodla aşina olmadığında özellikle önemlidir.

Bu konudaki fikriniz nedir?

Hayır, assertistediğiniz gibi kullandığınız sürece yanlış bir şey yoktur .

Yani, normal hata işlemenin aksine, hata ayıklama sırasında "gerçekleşemeyen" vakaları yakalamak için olması gerekiyordu.

• Assert: Programın mantığındaki bir hata.
• Hata İşleme: Programdaki bir hata nedeniyle hatalı giriş veya sistem durumu.

Hayır, ne gotoneassert kötülük . Ancak her ikisi de yanlış kullanılabilir.

Assert akıl sağlığı kontrolleri içindir. Doğru değilse programı öldürmesi gereken şeyler. Doğrulama için değil veya hata işleme için değil.

Bu mantıkla kesme noktaları da kötülüktür.

Ekler, hata ayıklama yardımcısı olarak kullanılmalıdır ve başka bir şey kullanılmamalıdır. "Kötülük" onları kullanmayı denediğiniz zamandır hata işleme zamandır.

Varlıklar, programcıya, var olmaması gereken sorunları tespit edip düzeltmenize ve varsayımlarınızın doğru kaldığını doğrulamanıza yardımcı olmak için vardır.

Hata işleme ile hiçbir ilgileri yoktur, ancak ne yazık ki, bazı programcılar onları bu şekilde kötüye kullanır ve daha sonra "kötülük" ilan eder.

Assert kullanmayı çok seviyorum. Uygulamaları ilk kez oluştururken (belki de yeni bir alan için) çok yararlı buluyorum. (Erken optimizasyon düşünün) çok süslü hata denetimi yapmak yerine hızlı kod ve ekleri bir sürü ekleyin. İşlerin nasıl çalıştığı hakkında daha fazla bilgi edindikten sonra, bir yeniden yazma işlemi gerçekleştirir ve bazı ekleri kaldırır ve daha iyi hata işleme için değiştiririm.

Ekler nedeniyle kodlama / hata ayıklama programlarına çok daha az zaman harcıyorum.

Ayrıca, programların kırılabilecek birçok şeyi düşünmemde bana yardımcı olduğunu fark ettim.

Ek bir bilgi olarak go, yerleşik bir işlev sağlar panic. Bu yerine kullanılabilir assert. Örneğin

if x < 0 {
    panic("x is less than 0");
}

panicyığın izini yazdırır, böylece bir şekilde amacı vardır assert.

Programdaki hataları tespit etmek için kullanılmalıdırlar. Kötü kullanıcı girişi değil.

Doğru kullanılırsa, bunlar değil kötülük.

Bu çok ortaya çıkıyor ve bence iddiaların savunmasını kafa karıştırıcı yapan bir problem, genellikle argüman kontrolüne dayanıyor olmaları. Bir iddiayı ne zaman kullanabileceğinize ilişkin bu farklı örneği göz önünde bulundurun:

build-sorted-list-from-user-input(input)

    throw-exception-if-bad-input(input)

    ...

    //build list using algorithm that you expect to give a sorted list

    ...

    assert(is-sorted(list))

end

Girdi için bir istisna kullanıyorsunuz, çünkü bazen kötü girdi alacağınızı umuyorsunuz. Listenin, algoritmanızda tanımladığınız bir hata bulmanıza yardımcı olacak şekilde sıralandığını iddia edersiniz. İddia sadece hata ayıklama yapısındadır, bu nedenle kontrol pahalı olsa da, rutinin her bir çağrısında bunu yapmanın bir sakıncası yoktur.

Üretim kodunuzu yine de birim test etmeniz gerekiyor, ancak bu, kodunuzun doğru olduğundan emin olmanın farklı ve tamamlayıcı bir yoludur. Birim testleri, rutininizin arayüzüne uygun olmasını sağlarken, iddialarınız, uygulamanızın tam olarak beklediğiniz şeyi yaptığından emin olmak için daha ayrıntılı bir yöntemdir.

İddialar kötü değildir, ancak kolayca kötüye kullanılabilirler. "Doğru hata işleme ve raporlama hakkında düşünmekten kaçınmak için iddiaların sık sık koltuk değneği olarak kullanıldığı" ifadesine katılıyorum. Bunu oldukça sık gördüm.

Şahsen, kodlarımı yazarken yapmış olabileceğim varsayımları belgelediğinden iddiaları kullanmayı seviyorum. Kod korunurken bu varsayımlar bozulursa, sorun test sırasında tespit edilebilir. Ancak, ben bir üretim inşa (yani, #ifdefs kullanarak) yaparken benim kod her iddia dışarı sıyırma noktası yapmak. Üretim yapısındaki iddiaları çıkararak, onları koltuk değneği olarak kötüye kullanma riskini ortadan kaldırıyorum.

İddialarla ilgili başka bir sorun daha var. İddialar sadece çalışma zamanında kontrol edilir. Ancak genellikle yapmak istediğiniz kontrolün derleme zamanında yapılmış olabileceği düşünülmektedir. Bir sorunun derleme zamanında tespit edilmesi tercih edilir. C ++ programcıları için boost, bunu yapmanızı sağlayan BOOST_STATIC_ASSERT sağlar. C programcıları için, bu makalede ( bağlantı metni ) derleme zamanında iddiaları gerçekleştirmek için kullanılabilecek bir teknik açıklanmaktadır.

Özet olarak, takip ettiğim temel kural şudur: Bir üretim yapısında iddiaları kullanmayın ve mümkünse yalnızca derleme zamanında doğrulanamayan şeyler için iddiaları kullanın (yani, çalışma zamanında kontrol edilmelidir).

Uygun hata bildirimi göz önüne alınmadan ekler kullandığını itiraf ediyorum. Ancak, doğru kullanıldıklarında çok yardımcı olduklarını ortadan kaldırmazlar.

Özellikle "Crash Early" ilkesini takip etmek istiyorsanız özellikle kullanışlıdır. Örneğin, bir referans sayma mekanizması uyguladığınızı varsayalım. Kodunuzdaki belirli yerlerde yeniden sayımın sıfır veya bir olması gerektiğini bilirsiniz. Ayrıca, yeniden sayım yanlışsa programın hemen çökmeyeceğini, ancak bir sonraki mesaj döngüsünde hangi noktanın yanlış gittiğini bulmanın zor olacağını varsayalım. Bir iddia, hatanın kaynağına yakın tespit edilmesinde yardımcı olacaktır.

Hata ayıklama ve sürümde farklı şeyler yapan kod kaçınmayı tercih ederim.

Hata ayıklayıcıyı bir koşulda kırmak ve tüm dosya / satır bilgilerine sahip olmak, aynı zamanda tam ifade ve tam değer de yararlıdır.

"Durumu sadece hata ayıklamada değerlendirecek" bir iddiaya sahip olmak, bir performans optimizasyonu olabilir ve bu nedenle, programların sadece% 0.0001'inde yararlı olabilir - insanların ne yaptığını bildiği yerlerde. Diğer tüm durumlarda bu zararlıdır, çünkü ifade aslında programın durumunu değiştirebilir:

assert(2 == ShroedingersCat.GetNumEars()); Programın hata ayıklama ve bırakmada farklı şeyler yapmasını sağlar.

Bir istisna atacak ve hem hata ayıklama hem de yayın sürümünde yapacak bir dizi onaylama makrosu geliştirdik. Örneğin, THROW_UNLESS_EQ(a, 20);ne () iletisinin hem dosya, satır hem de gerçek değerlerine sahip olduğu bir istisna atar . Sadece bir makronun buna gücü vardır. Hata ayıklayıcı, belirli kural dışı durum türünün 'atışında' kırılmak üzere yapılandırılabilir.

Ben şiddetle sevmiyorum sevmiyorum. Gerçi kötü olduklarını söyleyecek kadar ileri gitmem.

Temel olarak, bir iddia sahibi kontrol edilmeyen bir istisna ile aynı şeyi yapacaktır, tek istisna, onaylayıcının (normalde) nihai ürün için saklanmaması gerektiğidir.

Sistemde hata ayıklama ve oluşturma sırasında kendiniz için bir güvenlik ağı oluşturursanız, bu güvenlik ağını neden müşteriniz, destek yardım masanız veya şu anda oluşturduğunuz yazılımı kullanacak olanlar için inkar edersiniz. İstisnaları yalnızca hem varsayımlar hem de istisnai durumlar için kullanın. Uygun bir istisna hiyerarşisi oluşturarak birini diğerinden çok çabuk fark edebileceksiniz. Bu süre zarfında iddia eden kişi yerinde kalır ve aksi takdirde kaybedilecek bir arıza durumunda değerli bilgiler sağlayabilir.

Bu yüzden, Go'yu oluşturanları, varsayımları tamamen kaldırarak ve programcıları durumu ele almak için istisnalar kullanmaya zorlayarak tam olarak anlıyorum. Bunun basit bir açıklaması var, istisna sadece arkaik iddialara sadık kalmak için iş için daha iyi bir mekanizmadır?

Kısa cevap: Hayır, iddiaların yararlı olabileceğine inanıyorum

Son zamanlarda koduma bazı ekler eklemeye başladım ve ben de bunu yapıyorum:

Zihnimi zihinsel olarak sınır koduna ve iç koda bölerim. Sınır kodu, kullanıcı girişini işleyen, dosyaları okuyan ve ağdan veri alan koddur. Bu kodda, yalnızca girdi geçerli olduğunda (etkileşimli kullanıcı girdisi durumunda) çıkan bir döngüde giriş ister veya kurtarılamayan dosya / ağ bozuk verileri durumunda istisnalar atarım.

Dahili kod her şeydir. Örneğin, sınıfımda bir değişken ayarlayan bir işlev şu şekilde tanımlanabilir:

void Class::f (int value) {
    assert (value < end);
    member = value;
}

ve bir ağdan girdi alan bir işlev şöyle okunabilir:

void Class::g (InMessage & msg) {
    int const value = msg.read_int();
    if (value >= end)
        throw InvalidServerData();
    f (value);
}

Bu bana iki kat kontrol sağlıyor. Verilerin çalışma zamanında belirlendiği her şey her zaman bir istisna veya anında hata işleme alır. Ancak, ifadeyle Class::fyapılan bu ekstra kontrol, assertbazı iç kodların çağrılması durumunda Class::f, hala bir sağlık kontrolü yaptığım anlamına gelir . Dahili kodum geçerli bir argüman iletmeyebilir (çünkü valuebazı karmaşık fonksiyon serilerinden hesaplamış olabilirim ), bu yüzden fonksiyonu kimin çağırdığına bakılmaksızın, ayar fonksiyonundaki iddianın valuedaha büyük veya eşittir end.

Bu, birkaç yerde okuduğum şeye uyuyor gibi görünüyor, iyi işleyen bir programda iddiaların ihlal edilmesi imkansız olmalı, istisnalar hala mümkün olan istisnai ve hatalı durumlar için olmalıdır. Teoride tüm girdileri doğruladığım için iddiamın tetiklenmesi mümkün olmamalı. Eğer öyleyse, programım yanlış.

Eğer bahsettiğiniz varsayımlar programın kusup sonra var olduğu anlamına gelirse, iddialar çok kötü olabilir. Bu her zaman oldukları anlamına gelmez kullanmak için yanlış bir şey oldukları anlamına gelmez, çok kolay kötüye kullanılan bir yapıdır. Ayrıca çok daha iyi alternatifleri var. Bunun gibi şeyler kötülük olarak adlandırılmak için iyi adaylardır.

Örneğin, 3. taraf bir modül (veya herhangi bir modül) çağıran programdan neredeyse hiç çıkmamalıdır. Bu, çağıran programcıya, programın o anda alması gereken risk üzerinde herhangi bir kontrol sağlamaz. Çoğu durumda, veriler o kadar önemlidir ki, bozuk verilerin kaydedilmesi bile bu verileri kaybetmekten daha iyidir. Ekler sizi veri kaybetmeye zorlayabilir.

İddialara bazı alternatifler:

• Bir hata ayıklayıcı kullanarak,
• Konsol / veritabanı / diğer günlük kaydı
• İstisnalar
• Diğer hata işleme türleri

Bazı referanslar:

• http://ftp.gnu.org/old-gnu/Manuals/nana-1.14/html_node/nana_3.html
• http://www.lenholgate.com/blog/2005/09/assert-is-evil.html
• Go'nun iddialarda bulunmaması ve bunun için iyi nedenleri vardır: http://golang.org/doc/faq#assertions
• http://c2.com/cgi/wiki?DoNotUseAssertions

İddiayı savunan insanlar bile üretimde değil , yalnızca gelişimde kullanılmaları gerektiğini düşünmektedir :

• http://codebetter.com/gregyoung/2007/12/12/asserts-are-not-evil/
• http://www.codeproject.com/Articles/6404/Assert-is-your-friend
• http://parabellumgames.wordpress.com/using-asserts-for-debugging/

Bu kişi, modülün bir istisna atıldıktan sonra devam eden potansiyel olarak bozuk veriler olduğunda kullanılması gerektiğini söylüyor: http://www.advogato.org/article/949.html . Bu kesinlikle makul bir noktadır, ancak harici bir modül asla çağrılan program için bozuk verilerin ne kadar önemli olduğunu reçete etmemelidir (onlar için "çıkarak"). Bunu ele almanın doğru yolu, programın şimdi tutarsız bir durumda olabileceğini açıkça belirten bir istisna atmaktır. İyi programlar çoğunlukla modüller içerdiğinden (ana yürütülebilir dosyada küçük bir tutkal kodu ile), iddialar hemen hemen her zaman yanlış şeydir.

assert çok kullanışlıdır ve beklenmedik hatalar meydana geldiğinde programı ilk sorun belirtilerinde durdurarak size çok fazla geri izleme kaydedebilirsiniz.

Öte yandan, kötüye kullanımı çok kolaydır assert.

int quotient(int a, int b){
    assert(b != 0);
    return a / b;
}

Doğru, doğru sürüm şöyle bir şey olacaktır:

bool quotient(int a, int b, int &result){
    if(b == 0)
        return false;

    result = a / b;
    return true;
}

Yani ... uzun vadede ... büyük resimde ... assertbunun kötüye kullanılabileceğini kabul etmeliyim . Onu her zaman yaparım.

assert daha az yazdığı için hata işleme nedeniyle kötüye kullanılıyor.

Dolayısıyla, dil tasarımcıları olarak, daha az yazarak doğru hata işlemenin yapılabileceğini görmelidirler. İstisna mekanizmanızın ayrıntılı olması nedeniyle iddiayı hariç tutmak çözüm değildir. Oh bekleyin, Go'nun da istisnaları yok. Çok kötü :)

Bunu görünce kafamda yazar tekmelemek gibi hissettim.

Ben kod her zaman ekler kullanın ve ben daha fazla kod yazarken sonunda hepsini değiştirin. Gerekli mantığı yazmadım ve proje tamamlanmaya yaklaştıkça silinecek bir istisna yazmak yerine koda girdiğimde uyarılmak istiyorum.

İstisnalar, sevmediğim üretim koduyla daha kolay uyum sağlar. Bir iddiayı farketmekten daha kolaydırthrow new Exception("Some generic msg or 'pretend i am an assert'");

Bu cevapları savunmayı savunanlarla ilgili sorunum, kimsenin onu normal bir ölümcül hatadan neyin farklı kıldığını ve neden bir savunucunun bir istisnanın alt kümesi olamayacağını açıkça belirtmemesi . Şimdi, bununla birlikte, ya istisna asla yakalanmazsa? Bu isimlendirme ile bir iddia mı ediyor? Ve neden, dilde / hiçbir şeyin / işleyemeyeceği bir istisna doğurabileceğine dair bir kısıtlama getirmek istesin ki?

Evet, iddialar kötüdür.

Genellikle uygun hata işlemenin kullanılması gereken yerlerde kullanılırlar. Başlangıçtan itibaren uygun üretim kalitesi hata işlemeye yazmaya alışın!

Genellikle birim testleri yazma yoluna girerler (test kemerinizle etkileşime giren özel bir onay yazmazsanız). Bunun nedeni genellikle uygun hata işlemenin kullanılması gereken yerlerde kullanılmasıdır.

Çoğunlukla yayın yapılarından derlenirler; bu, gerçekten yayınladığınız kodu çalıştırdığınızda "testlerinin" hiçbirinin kullanılamayacağı anlamına gelir; Çok iş parçacıklı durumlarda en kötü sorunların genellikle yalnızca sürüm kodunda gösterilmesi kötü olabilir.

Bazen başka türlü kırık tasarımlar için bir koltuk değneği; yani kodun tasarımı bir kullanıcının kodu çağrılmaması gereken bir şekilde çağırmasına izin verir ve iddia eden kişi bunu "önler". Tasarımı düzeltin!

Bu konuyu 2005 yılında blogumda yazdım: http://www.lenholgate.com/blog/2005/09/assert-is-evil.html

Genel olarak ters verim kadar kötü değil. Kalıcı hata kontrolü ile hata ayıklama arasında bir ayrım vardır. Assert, tüm hata ayıklama işlemlerinin kalıcı olması gerektiğini düşünmesini sağlar ve çok kullanıldığında büyük okunabilirlik sorunlarına neden olur. Kalıcı hata işleme, gerektiğinden daha iyi olmalıdır ve iddia kendi hatalarına neden olduğu için oldukça tartışmalı bir uygulamadır.

Asla assert () kullanın, örnekler genellikle böyle bir şey göstermek:

int* ptr = new int[10];
assert(ptr);

Bu kötü, bunu asla yapmam, ya oyunum bir sürü canavar tahsis ederse? neden oyunu çökmeli, bunun yerine hataları incelikle ele almalısınız, bu yüzden şöyle bir şey yapın:

CMonster* ptrMonsters = new CMonster[10];
if(ptrMonsters == NULL) // or u could just write if(!ptrMonsters)
{
    // we failed allocating monsters. log the error e.g. "Failed spawning 10 monsters".
}
else
{
    // initialize monsters.
}