Soyut istisna süper türü

Atma System.Exceptionbu kadar kötü kabul edilirse , neden ilk etapta Exceptionyapılmadı abstract?

Bu şekilde aramak mümkün olmazdı:

throw new Exception("Error occurred.");

Bu, oluşan hata hakkında daha fazla ayrıntı sağlamak için türetilmiş istisnalar kullanılmasını zorunlu kılar.

Örneğin, bir kütüphane için özel bir istisna hiyerarşisi sağlamak istediğimde, istisnalarım için genellikle soyut bir temel sınıf bildiririm:

public abstract class CustomExceptionBase : Exception
{
    /* some stuff here */
}

Ve sonra daha spesifik bir amaç için türetilen bir istisna:

public class DerivedCustomException : CustomExceptionBase
{
    /* some more specific stuff here */
}

Daha sonra herhangi bir kütüphane yöntemini çağırırken, kütüphaneden gelen herhangi bir hatayı doğrudan yakalamak için bu genel try / catch bloğu olabilir:

try
{
    /* library calls here */
}
catch (CustomExceptionBase ex)
{
    /* exception handling */
}

Bu iyi bir uygulama mı?

ExceptionSoyut yapılsaydı iyi olur mu?

EDIT: Burada benim bir istisna sınıfı işaretlenmiş olsa bile abstract, yine de bir tümünü yakala blok yakalayabilirsiniz. Özetlemek, programcıların "süper geniş" bir istisna atmasını yasaklamanın bir yoludur. Genellikle, gönüllü olarak bir istisna attığınızda, bunun ne tür olduğunu ve neden olduğunu bilmelisiniz. Böylece daha özel bir istisna türü atmaya zorlamak.

Bunun bu şekilde yapılmasının gerçek nedenlerini bilmiyorum ve bir dereceye kadar, sonsuz geniş istisnaların atılmasının önlenmesinin iyi bir şey olacağını kabul ediyorum.

AMA ... küçük demo uygulamaları veya kanıt kanıtı kodlarken, 10 farklı istisna alt sınıfı tasarlamaya başlamak ya da durum için "en iyi" istisna sınıfı hangisinin olduğuna karar vermeye çalışırken zaman harcamak istemiyorum. Sadece Exceptionayrıntıları açıklayan bir ip atmak ve geçmek istiyorum . Olsam atımı-away kod, bu tür şeylerde umurumda olmadığı ve zorla böyle şeyleri bakım, ben de kendi oluşturmak istiyorum GenericExceptionsınıf ve atmak o yerde, ya da farklı bir aracı / diline hareket. Bazı projeler için, ilgili İstisna alt sınıflarının uygun şekilde oluşturulmasının önemli olduğunu kabul ediyorum, ancak tüm projeler bunu gerektirmiyor.

Olasılık A: Mantıken doğru.

Microsoft'un, birçoğu ile birlikte, çok sayıda new Exception()nedenden dolayı doğrudan bir atma önermediğini haklıyorsunuz .

Bununla birlikte, bir Exceptionsınıf hiyerarşisinin amacının sadece en özel istisnaların yakalanabilmesi için daraltıcı bir etki tanımlamak olduğu akademik ideali düşünebiliriz . (yani ArgumentNullExceptiondaha dar ArgumentException).

İstisna sınıfı bir istisna değildir (pun amaçlanmamıştır). Mümkün olan en geniş istisna, kapsamı sonsuza kadar geniş olduğu için neredeyse yakalanamayan bir "süper istisna" olması amaçlanmıştır. 'İstisna' abstract, İstisna'nın kendi başına bir varlık olarak var olmaması anlamında değildir. Henüz kabul edilebilir olsa da, henüz iyi bir durum tanımlanmamıştır - bkz. Olasılık B) ve dolayısıyla kamuya açık bir şekilde inşa edilebilir olmalıdır.

'Soyut' anahtar kelime (tamamen akademik anlamda) yalnızca temel sınıf tek başına bir anlam ifade etmediğinde geçerlidir - ör FourLeggedAnimal.

Bunu göz önünde bulundurarak Bütün hayır olacağını teknik sınıf yapmaya nedeni abstract, geliştiriciler için tırmandığı bir kaynak olmaya dışında .

Olasılık B: Tasarım Kilitleme / Bilmiyorlardı

Eğer MS bu sınıfı soyutlaştırırsa, bu sınıf dilin temelleri için çok önemli olduğundan, fikirlerini yoldan değiştirmeleri durumunda başları belada olabilir. Zaten gözlerini kestiler ApplicationException, bu yüzden de yolun aşağısında tavsiyede bir değişiklik bekledikleri öngörülebilir. (bkz. http://blogs.msdn.com/b/kcwalina/archive/2006/06/23/644822.aspx )

Başka nedenler de olabilir (bunun belki de Yansıma ya da başka bir teknik nedenden dolayı olduğunu düşünüyorum), bu yüzden bu yazıyı CW yapıyorum.