Geçersiz bir genel tür bağımsız değişkeni için en iyi istisna

Şu anda UnconstrainedMelody için numaralandırmalarla ilgili genel yöntemler içeren bazı kodlar yazıyorum .

Şimdi, sadece "bayraklar" numaralandırmalarıyla kullanılması amaçlanan bir dizi yöntem içeren statik bir sınıfım var . Bunu bir kısıtlama olarak ekleyemiyorum ... bu yüzden diğer enum türleriyle de çağrılmaları mümkün. Bu durumda bir istisna yapmak isterim ama hangisini atacağımdan emin değilim.

Bunu somutlaştırmak için, eğer böyle bir şeye sahipsem:

// Returns a value with all bits set by any values
public static T GetBitMask<T>() where T : struct, IEnumConstraint
{
    if (!IsFlags<T>()) // This method doesn't throw
    {
        throw new ???
    }
    // Normal work here
}

Fırlatılacak en iyi istisna nedir? ArgumentExceptionkulağa mantıklı geliyor, ancak bu, normal bir argüman olmaktan çok, bir şeyleri kolayca karıştırabilecek bir tip argümanı. Kendi TypeArgumentExceptionsınıfımı tanıtmalı mıyım ? Kullan InvalidOperationException? NotSupportedException? Başka herhangi bir şey?

Açıkça yapılacak doğru şey olmadıkça, bunun için kendi istisnamı yaratmamayı tercih ederim .

NotSupportedException sesler böyle uyuyor açıkça, ancak belgeler açıkça farklı bir amaç için kullanılması gerektiğini belirtmektedir. MSDN sınıfından açıklamalar:

Temel sınıfta desteklenmeyen yöntemler vardır, bunun yerine bu yöntemlerin türetilmiş sınıflarda uygulanacağı beklentisi vardır. Türetilmiş sınıf, temel sınıftan yöntemlerin yalnızca bir alt kümesini uygulayabilir ve desteklenmeyen yöntemler için NotSupportedException oluşturabilir.

Tabii ki, NotSupportedExceptionözellikle sağduyu anlamı göz önüne alındığında, yeterince iyi olduğu açıkça belli olan bir yol var . Bunu söyledikten sonra, doğru olup olmadığından emin değilim.

Unconstrained Melody'nin amacı göz önüne alındığında ...

"T: enum" veya "T: delegate" tür kısıtlamalarının olduğu genel yöntemlerle / sınıflarla yapılabilecek çeşitli yararlı şeyler vardır - ancak maalesef bunlar C # 'da yasaklanmıştır.

Bu yardımcı program kitaplığı ildasm / ilasm kullanarak yasaklar etrafında çalışır ...

... Exceptionözel oluşturmadan önce sadece buluşmamız gereken yüksek kanıt yüküne rağmen yeni bir sıra olabilir gibi görünüyor Exceptions. Bu tür bir şey InvalidTypeParameterExceptionkütüphane genelinde faydalı olabilir (veya olmayabilir - bu kesinlikle bir uç durumdur, değil mi?).

Müşterilerin bunu BCL İstisnalarından ayırt edebilmesi gerekecek mi? Bir müşteri bunu yanlışlıkla vanilya kullanarak ne zaman arayabilir enum? Özel bir istisna sınıfı yazarken hangi faktörler dikkate alınmalıdır? Sorusunun kabul edilen cevabının sorduğu soruları nasıl cevaplarsınız ?

NotSupportedException'dan kaçınırdım. Bu istisna, bir yöntemin uygulanmadığı çerçevede kullanılır ve bu tür işlemin desteklenmediğini belirten bir özellik vardır. Buraya sığmıyor

• Utanmaz kendi kendine Referans: http://blogs.msdn.com/jaredpar/archive/2008/12/12/notimplementedexception-vs-notsupportedexception.aspx

Bence InvalidOperationException buraya atabileceğiniz en uygun istisna.

Geçersiz tür parametreleri için genel programlama çalışma zamanında atılmamalıdır. Derlenmemeli, derleme zamanı yaptırımına sahip olmalısınız. Neyi IsFlag<T>()içerdiğini bilmiyorum , ama belki bunu bir derleme zamanı yaptırımına dönüştürebilirsiniz, örneğin sadece 'bayraklar' ile yaratılması mümkün olan bir tür yaratmaya çalışmak gibi. Belki bir traitssınıf yardımcı olabilir.

Güncelleme

Eğer varsa gerekir atmak, ben ınvalidoperationexception oy verirdim. Gerekçe , genel türlerin parametrelere sahip olması ve (yöntem) parametreleriyle ilgili hataların ArgumentException hiyerarşisi etrafında ortalanmasıdır. Ancak, ArgumentException ile ilgili öneri şunu belirtir:

başarısızlık bağımsız değişkenleri içermiyorsa, InvalidOperationException kullanılmalıdır.

Burada en az bir inanç sıçraması var, yöntem parametreleri önerileri genel parametrelere de uygulanacak , ancak SystemException hierachy imho'da daha iyi bir şey yok.

NotSupportedException'ı söylediğiniz gibi kullanırdım. Belirli olanlar dışındaki diğer numaralandırmalar desteklenmez . Bu, elbette istisna mesajında ​​daha açık bir şekilde ifade edilecektir.

Ben giderdim NotSupportedException. İyi görünse de ArgumentException, bir yönteme iletilen bir argümanın kabul edilemez olması gerçekten beklenir. Bir tür bağımsız değişkeni, gerçek bir "bağımsız değişken" değil, çağırmak istediğiniz gerçek yöntem için tanımlayıcı bir özelliktir. InvalidOperationExceptionGerçekleştirdiğiniz işlem bazı durumlarda geçerli olduğunda atılmalıdır, ancak belirli bir durum için kabul edilemez.

NotSupportedExceptionbir işlem doğası gereği desteklenmediğinde atılır. Örneğin, belirli bir üyenin bir sınıf için anlamlı olmadığı bir arabirim uygularken. Bu benzer bir duruma benziyor.

Görünüşe göre, Microsoft, kullandığı ArgumentExceptionörneği üzerinde gösterildiği gibi, bunun için Expression.Lambda <> , Enum.TryParse <> veya Marshal.GetDelegateForFunctionPointer <> İstisnalar bölümünde. Ben de aksini gösteren herhangi bir örnek bulamadım ( TDelegateve için yerel referans kaynağı aramasına rağmen TEnum).

Bu nedenle, en azından Microsoft kodunda ArgumentException, temel değişkenler dışında geçersiz genel tür bağımsız değişkenler için kullanılmasının yaygın bir uygulama olduğunu varsaymanın güvenli olduğunu düşünüyorum . Dokümanlardaki istisna tanımının bunlar arasında ayrım yapmadığı göz önüne alındığında , bu da çok fazla bir zorunluluk değildir.

Umarım soruya kesin olarak karar verir.

Id NotSupportedExpcetion ile devam edin.

Özel yapılmış bir istisna, şüpheli olduğu her durumda her zaman yapılmalıdır. Özel bir istisna, API kullanıcılarının ihtiyaçları ne olursa olsun her zaman işe yarar. Geliştirici umursamazsa herhangi bir istisna türünü yakalayabilir, ancak geliştiricinin özel bir işleme ihtiyacı varsa, SOL olacaktır.

NotSupportedException'dan devralmaya ne dersiniz? @Mehrdad ile en mantıklı olduğu konusunda hemfikir olsam da, tam olarak uymadığını duyduğunuzu duydum. Bu nedenle, NotSupportedException'dan devralın ve bu şekilde API'nize karşı kodlama yapan kişiler bir NotSupportedException'ı yakalayabilir.

Tamamen her zaman açıkça belgelenmedikleri ve doğru adlandırılmadıkları takdirde kafa karışıklığına neden oldukları gerekçesiyle özel istisnalar yazmaktan her zaman çekinirim.

Bu durumda, bayrak kontrolü başarısızlığı için bir ArgumentException oluştururum. Her şey gerçekten tercihe bağlı. Gördüğüm bazı kodlama standartları, bunun gibi senaryolarda hangi tür istisnaların atılması gerektiğini tanımlayacak kadar ileri gider.

Kullanıcı bir numaralandırma olmayan bir şeyi geçirmeye çalışıyorsa, bir InvalidOperationException atardım.

Düzenle:

Diğerleri bunun desteklenmediği konusunda ilginç bir noktaya işaret ediyor. NotSupportedException ile ilgili tek endişem, genellikle sisteme "karanlık madde" eklendiğinde ortaya çıkan istisnalar veya başka bir deyişle, "Bu yöntem bu arayüzde sisteme girmeli, ancak kazandık "2.4" sürümüne kadar açmayın "

NotSupportedExceptions'ın bir lisans istisnası olarak atıldığını da gördüm "bu yazılımın ücretsiz sürümünü çalıştırıyorsunuz, bu işlev desteklenmiyor".

Düzenleme 2:

Bir başka olası:

System.ComponentModel.InvalidEnumArgumentException  

Numaralandırıcı olan geçersiz bağımsız değişkenler kullanılırken atılan istisna.

Ayrıca InvalidOperationException için oy kullanırdım. Framework Design Guidelines 2nd Ed'e dayalı olarak .NET istisna atma yönergelerinde (eksik) bir akış şeması yaptım . ilgilenen varsa bir süre geri dönerim.