.NET'te geçersiz veya beklenmeyen parametreler için hangi özel durumlar atılmalıdır?

.NET'te geçersiz veya beklenmeyen parametreler için ne tür özel durumlar atılmalıdır? Birini ne zaman diğeri yerine seçerim?

Takip et:

Bir aya karşılık gelen bir tamsayı bekleyen bir işleve sahipseniz ve '42'de geçtiyseniz, hangi istisnayı kullanırsınız? Bu bir koleksiyon olmasa da "kapsam dışı" kategorisine girer mi?

: Ben kullanım ister ArgumentException, ArgumentNullExceptionve ArgumentOutOfRangeException.

• ArgumentException - Argümanla ilgili bir sorun var.
• ArgumentNullException - Tartışma boş.
• ArgumentOutOfRangeException - Bunu çok kullanmıyorum, ancak yaygın bir kullanım bir koleksiyona dizin oluşturmak ve büyük bir dizin vermek.

Argümanın kendisine çok fazla odaklanmayan, ancak çağrıyı bir bütün olarak yargılayan başka seçenekler de var:

• InvalidOperationException- Bağımsız değişken OK olabilir, ancak nesnenin geçerli durumunda olmayabilir. ^{_{Kredi STW'ye (önceden Yoooder) gidiyor. Oy cevabını yanı yukarı.}}
• NotSupportedException- Aktarılan argümanlar geçerli, ancak bu uygulamada desteklenmiyor. Bir FTP istemcisi düşünün ve istemcinin desteklemediği bir komut iletin.

İşin püf noktası, yöntemin neden bu şekilde adlandırılamayacağını en iyi ifade eden istisnayı atmaktır. İdeal olarak, istisna neyin yanlış gittiğini, niçin yanlış olduğu ve nasıl düzeltileceği hakkında ayrıntılı olmalıdır.

Hata mesajları yardıma, belgelere veya diğer kaynaklara işaret ettiğinde seviyorum. Örneğin, Microsoft, KB makaleleriyle iyi bir ilk adım attı, örneğin “Internet Explorer'da bir Web sayfasını ziyaret ettiğimde neden" İşlem iptal edildi "hata iletisini alıyorum?" . Hatayla karşılaştığınızda, hata iletisindeki KB makalesine yönlendirirsiniz. İyi yapmadığı şey size söylemedikleri, neden özellikle başarısız olduğu.

^{_{Yorumlar için STW (eski Yoooder) tekrar teşekkürler.}}

İzleminize yanıt olarak, bir ArgumentOutOfRangeException. MSDN'nin bu istisna hakkında ne söylediğine bakın:

ArgumentOutOfRangeExceptionbir yöntem çağrıldığında ve yönteme iletilen bağımsız değişkenlerden en az biri null başvuru ( NothingVisual Basic'te) olmadığında ve geçerli bir değer içermediğinde atılır .

Dolayısıyla, bu durumda, bir değer geçiriyorsunuz, ancak aralığınız 1–12 olduğundan geçerli bir değer değil. Bununla birlikte, bunu belgeleme şekliniz, API'nızın ne attığını netleştirir. Çünkü söylesem de ArgumentOutOfRangeException, başka bir geliştirici söyleyebilir ArgumentException. Kolaylaştırın ve davranışı belgeleyin.

Josh'un cevabına oy verdim , ancak listeye bir tane daha eklemek istiyorum:

Bağımsız değişken geçerliyse, System.InvalidOperationException oluşturulmalıdır, ancak nesne, bağımsız değişkenin kullanılmaması gereken bir durumdadır.

MSDN'den Alınan Güncelleme :

InvalidOperationException, yöntem çağırma başarısızlığının geçersiz bağımsız değişkenler dışındaki nedenlerden kaynaklandığı durumlarda kullanılır.

Diyelim ki nesnenizde PerformAction (enmSomeAction eylemi) yöntemi var, geçerli enmSomeActions Açık ve Kapalı. PerformAction (enmSomeAction.Open) öğesini arka arkaya iki kez çağırırsanız, ikinci çağrı InvalidOperationException özel durumunu (argüman geçerli olduğu için, ancak denetimin geçerli durumu için değil) atmalıdır.

Zaten defansif olarak programlayarak doğru olanı yaptığınızdan, ObjectDisposedException'dan bahsetmem gereken bir istisna daha var. Eğer senin nesne uygular sonra ıdisposable her zaman elden çıkarılan durumunu izleme Bir sınıf değişkeni sahip olmalıdır; nesneniz atılmışsa ve üzerinde bir yöntem çağrılmışsa, ObjectDisposedException öğesini yükseltmelisiniz:

public void SomeMethod()
{
    If (m_Disposed) {
          throw new ObjectDisposedException("Object has been disposed")
     }
    // ... Normal execution code
}

Güncelleme: İzleminizi cevaplamak için: Bu, belirsiz bir durumdur ve belirli bir veri kümesini temsil etmek için kullanılan genel (.NET Generics anlamda değil) veri türü tarafından biraz daha karmaşık hale getirilmiştir; bir enum veya diğer güçlü bir şekilde yazılmış bir nesne daha ideal bir uyum olacaktır - ancak her zaman bu kontrole sahip değiliz.

Şahsen ArgumentOutOfRangeException doğru yalın ve geçerli değerleri 1-12 olduğunu gösteren bir ileti sağlar. Benim gerekçem aylar hakkında konuştuğunuzda, ayların tamsayı temsillerinin geçerli olduğunu varsayarak, 1-12 aralığında bir değer beklediğinizdir. Sadece belirli aylar (31 güne sahip aylar gibi) geçerli olsaydı, o zaman aralık başına bir aralıkla uğraşmazsınız ve geçerli değerleri belirten genel bir ArgumentException atardım ve bunları yöntemin yorumlarında da belgeleyeceğim.

Gerçek değere ve hangi istisnanın en uygun olduğuna bağlı olarak:

• ArgumentException (değerle ilgili bir sorun var)

• ArgumentNullException (buna izin verilmezken argüman null olur)

• ArgumentOutOfRangeException (bağımsız değişken geçerli aralığın dışında bir değere sahip)

Bu yeterince kesin değilse, kendi istisna sınıfınızı türetmeniz yeterlidir ArgumentException.

Yoooder'in cevabı beni aydınlatıyordu. Bir girdidir geçersiz bir giriş iken o, her an geçerli değilse beklenmedik bu sistemin mevcut durumu için geçerli değilse. Yani sonraki durumda an InvalidOperationExceptionmakul bir seçimdir.

argüman istisnası.

• System.ArgumentException
• System.ArgumentNullException
• System.ArgumentOutOfRangeException

ArgumentException :

Bir yöntem çağrıldığında ve iletilen bağımsız değişkenlerden en az biri çağrılan yöntemin parametre belirtimini karşılamadığında ArgumentException oluşturulur. Tüm ArgumentException örnekleri, geçersiz bağımsız değişkeni ve bağımsız değişken için beklenen değer aralığını açıklayan anlamlı bir hata iletisi taşımalıdır.

Belirli geçersizlik türleri için de birkaç alt sınıf mevcuttur. Bağlantının alt türlerin özetleri ve ne zaman uygulanmaları gerektiği vardır.

Kısa cevap:
İkisi de

Daha uzun cevap:
Argument * Exception'ı kullanma (bileşen kitaplığı gibi üzerinde bulunan bir ürün olan bir kitaplık hariç) bir koku. İstisnalar, kullanıcının (yani API tüketicisi) eksikliklerini değil, hataları değil istisnai durumları ele almak içindir.

En uzun yanıt:
Bir kitaplık yazmadığınız sürece geçersiz bağımsız değişkenler için istisnalar atmak kaba olur.
İki (veya daha fazla) nedenden dolayı iddiaları kullanmayı tercih ediyorum:

• İddiaların test edilmesine gerek yoktur, ancak atma iddiaları yapar ve ArgumentNullException'a karşı test gülünç görünür (deneyin).
• İddialar, birimin amaçlanan kullanımını daha iyi iletir ve yürütülebilir bir sınıflamaya, sınıf davranışı belirtiminden daha yakındır.
• Onaylama ihlali davranışını değiştirebilirsiniz. Örneğin hata ayıklama derlemesinde bir mesaj kutusu iyidir, böylece KG'niz size hemen onunla vurur (IDE'nizin gerçekleştiği satırda kesilmesini sağlar), birim testinde onaylama hatasını bir test hatası olarak gösterebilirsiniz. .

Null istisnasının işlenmesi şöyle görünür (alaycı, açıkçası):

try {
    library.Method(null);
}
catch (ArgumentNullException e) {
    // retry with real argument this time
    library.Method(realArgument);
}

Durum beklendiği halde istisnai olduğunda istisnalar kullanılır (IO arızası gibi tüketicinin kontrolü dışında olan şeyler olur). Argüman * İstisna bir hatanın göstergesidir ve (benim görüşüm) testlerle ele alınacak ve Debug ile desteklenecektir.

BTW: Bu özel durumda, int yerine Month türünü kullanabilirsiniz. Tip güvenliği (Aspect # rulez!) Söz konusu olduğunda C # kısalır, ancak bazen bu hataları hep birlikte önleyebilir (veya derleme zamanında yakalayabilirsiniz).

Ve evet, MicroSoft bu konuda yanlış.

Kullanabileceğiniz standart bir ArgumentException var veya alt sınıfınızı oluşturabilir ve kendinizinkini oluşturabilirsiniz. Birkaç özel ArgumentException sınıfı vardır:

http://msdn.microsoft.com/en-us/library/system.argumentexception(VS.71).aspx

Hangisi en iyi çalışırsa.