Hata Ayıkla.Assert - Exception Throwing

İddiaların nasıl ve ne zaman kullanılacağına dair çok sayıda makale (ve StackOverflow'da yayınlanan birkaç benzer soru) okudum ve onları iyi anladım. Ama yine de, Debug.Assertbasit bir istisna atmak yerine beni ne tür bir motivasyon kullanmaya itmesi gerektiğini anlamıyorum . Demek istediğim, .NET'te başarısız bir iddiaya verilen varsayılan yanıt "dünyayı durdurmak" ve kullanıcıya bir mesaj kutusu göstermektir. Bu tür bir davranış değiştirilebilir olsa da, bunu yapmak için oldukça can sıkıcı ve gereksiz buluyorum, bunun yerine uygun bir istisna atabilirim. Bu şekilde, istisnayı atmadan hemen önce hatayı uygulamanın günlüğüne kolayca yazabilirim ve ayrıca uygulamamın donması gerekmez.

Öyleyse neden Debug.Assertbasit bir istisna yerine kullanmalıyım ? Olmaması gereken bir yere bir iddia yerleştirmek sadece her türlü "istenmeyen davranışa" neden olabilir, bu yüzden benim bakış açıma göre, bir istisna atmak yerine bir iddia kullanarak gerçekten hiçbir şey kazanmıyorum. Bana katılıyor musun yoksa burada bir şey mi eksik?

Not: "Teoride" farkın ne olduğunu tam olarak anlıyorum (Hata Ayıklama ve Yayınlama, kullanım kalıpları vb.), Ancak gördüğüm kadarıyla, bir iddia yapmak yerine bir istisna atmam daha iyi olur. Bir üretim sürümünde bir hata keşfedilirse, yine de "iddia" nın başarısız olmasını isterim (sonuçta, "ek yük" gülünç derecede küçüktür), bu yüzden bunun yerine bir istisna atmam daha iyi olur.

Düzenleme: Gördüğüm gibi, bir iddia başarısız olursa, bu, uygulamanın bir tür bozuk, beklenmedik duruma girdiği anlamına gelir. Öyleyse neden idama devam etmek isteyeyim? Uygulamanın bir hata ayıklama veya yayın sürümünde çalışıp çalışmadığı önemli değildir. Aynı şey ikisi için de geçerli

Muhakemenizin makul olduğunu kabul etsem de - yani, bir iddia beklenmedik bir şekilde ihlal edilirse, fırlatarak yürütmeyi durdurmak mantıklıdır - şahsen iddialar yerine istisnaları kullanmam. İşte nedeni:

Başkalarının da söylediği gibi, iddialar imkansız olan durumları belgelemelidir , öyle ki imkansız olduğu iddia edilen durum oluşursa geliştirici bilgilendirilir. Buna karşılık istisnalar, istisnai, olası olmayan veya hatalı durumlar için bir kontrol akışı mekanizması sağlar, ancak imkansız durumlar için değildir. Benim için en önemli fark şudur:

• HER ZAMAN, belirli bir atış ifadesini uygulayan bir test senaryosu oluşturmak mümkün olmalıdır. Böyle bir test senaryosu oluşturmak mümkün değilse, programınızda asla çalışmayan bir kod yolunuz vardır ve bu, ölü kod olarak kaldırılmalıdır.

• Bir iddianın ateşlenmesine neden olan bir test senaryosu üretmek ASLA mümkün olmamalıdır. Bir iddia patlarsa, ya kod yanlıştır ya da iddia yanlıştır; her iki durumda da kodda bir şeyin değişmesi gerekir.

Bu yüzden bir iddiayı bir istisna ile değiştirmem. İddia gerçekten çalışamazsa, onu bir istisna ile değiştirmek, programınızda test edilemeyen bir kod yoluna sahip olduğunuz anlamına gelir . Test edilemeyen kod yollarından hoşlanmıyorum.

İddialar, programcının dünyayı anlamasını kontrol etmek için kullanılır. Bir iddia, ancak programcı yanlış bir şey yaptıysa başarısız olmalıdır. Örneğin, kullanıcı girişini kontrol etmek için asla bir onaylama kullanmayın.

"Gerçekleşemeyen" koşulları test eder. İstisnalar, "olmaması gereken ama olması gereken" koşullar içindir.

İddialar yararlıdır çünkü derleme zamanında (hatta çalışma zamanında) davranışlarını değiştirebilirsiniz. Örneğin, genellikle sürüm yapılarında, gereksiz ek yük getirdikleri için iddialar kontrol bile edilmez. Bu aynı zamanda dikkatli olunması gereken bir konudur: testleriniz uygulanmayabilir bile.

İddialar yerine istisnalar kullanırsanız bir miktar değer kaybedersiniz:

1. Kod daha ayrıntılıdır, çünkü bir istisnayı test etmek ve atmak en az iki satırdır, oysa bir iddia yalnızca bir satırdır.

2. Test ve atış kodunuz her zaman çalışır, iddialar ise derlenebilir.

3. Diğer geliştiricilerle iletişiminizi kaybedersiniz çünkü iddiaların, kontrol eden ve atan ürün kodundan farklı bir anlamı vardır. Gerçekten bir programlama iddiasını test ediyorsanız, bir iddia kullanın.

Daha fazla bilgi için: http://nedbatchelder.com/text/assert.html

DÜZENLEME: Gönderinizde yaptığınız düzenlemeye / nota yanıt olarak: Başarmaya çalıştığınız şeylerin türü için iddiaları kullanmak yerine istisnaları kullanmak doğru şey gibi görünüyor. Bence çarptığınız zihinsel engel, aynı amacı gerçekleştirmek için istisnalar ve iddialar düşünmeniz ve bu nedenle hangisinin kullanmanın 'doğru' olacağını anlamaya çalışmanızdır. İddiaların ve istisnaların nasıl kullanılabileceği konusunda bazı örtüşmeler olsa da, aynı soruna farklı çözümler oldukları konusunda kafa karıştırmayın - öyle değiller. İddiaların ve İstisnaların her birinin kendi amacı, güçlü ve zayıf yönleri vardır.

Kendi sözlerimle bir cevap yazacaktım ama bu konsept benim sahip olacağımdan daha iyi bir adalet sağlıyor:

C # Station: Onaylar

Assert ifadelerinin kullanımı, çalışma zamanında program mantığı hatalarını yakalamak için etkili bir yol olabilir ve yine de üretim kodundan kolayca filtrelenebilir. Geliştirme tamamlandıktan sonra, kodlama hataları için bu fazlalık testlerin çalışma zamanı maliyeti, derleme sırasında önişlemci sembolü NDEBUG [tüm iddiaları devre dışı bırakır] tanımlanarak ortadan kaldırılabilir. Bununla birlikte, iddianın kendisine yerleştirilen kodun üretim sürümünde çıkarılacağını unutmayın.

Bir iddia, yalnızca aşağıdakilerin tümü geçerli olduğunda bir koşulu test etmek için en iyi şekilde kullanılır:

* the condition should never be false if the code is correct,
* the condition is not so trivial so as to obviously be always true, and
* the condition is in some sense internal to a body of software.

Yazılımın normal çalışması sırasında ortaya çıkan durumları tespit etmek için neredeyse hiçbir zaman iddialar kullanılmamalıdır. Örneğin, genellikle bir kullanıcının girdisindeki hataları kontrol etmek için iddialar kullanılmamalıdır. Bununla birlikte, arayanın bir kullanıcının girişini zaten kontrol ettiğini doğrulamak için iddiaları kullanmak mantıklı olabilir.

Temel olarak, bir üretim uygulamasında yakalanması / ele alınması gereken şeyler için istisnalar kullanın, geliştirme için yararlı olacak ancak üretimde kapatılacak mantıksal kontroller yapmak için iddiaları kullanın.

Bence (yapmacık) pratik bir örnek, farkı aydınlatmaya yardımcı olabilir:

( MoreLinq'in Batch uzantısından uyarlanmıştır )

// 'public facing' method
public int DoSomething(List<string> stuff, object doohickey, int limit) {

    // validate user input and report problems externally with exceptions

    if(stuff == null) throw new ArgumentNullException("stuff");
    if(doohickey == null) throw new ArgumentNullException("doohickey");
    if(limit <= 0) throw new ArgumentOutOfRangeException("limit", limit, "Should be > 0");

    return DoSomethingImpl(stuff, doohickey, limit);
}

// 'developer only' method
private static int DoSomethingImpl(List<string> stuff, object doohickey, int limit) {

    // validate input that should only come from other programming methods
    // which we have control over (e.g. we already validated user input in
    // the calling method above), so anything using this method shouldn't
    // need to report problems externally, and compilation mode can remove
    // this "unnecessary" check from production

    Debug.Assert(stuff != null);
    Debug.Assert(doohickey != null);
    Debug.Assert(limit > 0);

    /* now do the actual work... */
}

Yani olarak Eric Lippert ve ark söylediler, sadece doğru olmasını bekliyoruz bu şeyler assert, her ihtimale karşı sen (geliştirici) kazayla yanlış kullanmış kodunuzu çözebilmek için, başka bir yerde. Temelde, neyin geleceğini kontrol edemediğinizde veya önceden tahmin edemediğinizde istisnalar atarsınız, örneğin kullanıcı girdisi için , böylece kötü veriyi veren her ne ise uygun şekilde yanıt verebilir (örn. Kullanıcı).

Code Complete'den başka bir külçe :

"İddia, bir varsayım doğru değilse yüksek sesle şikayet eden bir işlev veya makrodur. Kodda yapılan varsayımları belgelemek ve beklenmedik durumları temizlemek için iddiaları kullanın. ...

"Geliştirme sırasında, iddialar çelişkili varsayımları, beklenmedik koşulları, rutinlere aktarılan kötü değerleri vb. Ortadan kaldırır."

Neyin ileri sürülmesi ve belirtilmemesi gerektiğine dair bazı yönergeler eklemeye devam ediyor.

Öte yandan istisnalar:

"Beklenmedik durumlara dikkat çekmek için istisna işlemeyi kullanın. İstisnai durumlar, geliştirme sırasında açık ve üretim kodu çalışırken kurtarılabilir olacak şekilde ele alınmalıdır."

Bu kitaba sahip değilseniz satın almalısınız.

Debug.Assert varsayılan olarak yalnızca hata ayıklama yapılarında çalışacaktır, bu nedenle sürüm yapılarınızda herhangi bir kötü beklenmeyen davranışı yakalamak istiyorsanız, proje özelliklerinizde istisnaları kullanmanız veya hata ayıklama sabitini açmanız gerekir ( genel olarak iyi bir fikir olmamak).

Şeyler için kullanın iddialar OLAN mümkün ama olmamalı (bir onaylama koymak neden bu mümkün olmazsa,?).

Kulağa bir dava gibi gelmiyor mu Exception? Neden bir iddia yerine bir iddia kullanasınız Exception?

Çünkü, iddianızın parametresinin yanlış olmasını durduracak, iddianızdan önce çağrılan bir kod olmalıdır.

Genellikle Exceptionatılmayacağını garanti etmeden önce hiçbir kod yoktur .

Debug.Assert()Üretimde derlenen neden iyidir ? Hata ayıklamada bunun hakkında bilgi edinmek istiyorsanız, üretimde bunu bilmek istemez miydiniz?

Bunu yalnızca geliştirme sırasında istersiniz, çünkü bir kez Debug.Assert(false)durum bulduğunuzda , Debug.Assert(false)bunun bir daha olmayacağını garanti etmek için kod yazarsınız . Geliştirme tamamlandıktan sonra, Debug.Assert(false)durumları bulduğunuzu ve düzelttiğinizi varsayarak Debug.Assert(), artık gereksiz oldukları için güvenli bir şekilde derlenebilirler.

Oldukça büyük bir ekibin üyesi olduğunuzu ve sınıflar üzerinde örtüşme dahil olmak üzere aynı genel kod tabanında çalışan birkaç kişi olduğunu varsayalım. Diğer birkaç yöntemle çağrılan bir yöntem yaratabilirsiniz ve kilit çekişmesini önlemek için ona ayrı bir kilit eklemeyin, bunun yerine arama yöntemi tarafından önceden belirli bir kilitle kilitlendiğini "varsayarsınız". Debug.Assert (RepositoryLock.IsReadLockHeld || RepositoryLock.IsWriteLockHeld) gibi; Diğer geliştiriciler, çağırma yönteminin kilidi kullanması gerektiğini söyleyen bir yorumu gözden kaçırabilir, ancak bunu göz ardı edemezler.