抽象异常超类型

如果System.Exception认为投掷很糟糕，为什么一开始就没有Exception做出abstract？

这样，将无法调用：

throw new Exception("Error occurred.");

这将强制使用派生异常来提供有关发生的错误的更多详细信息。

例如，当我想为库提供自定义异常层次结构时，通常会为我的异常声明一个抽象基类：

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

然后是一些派生的异常，其目的更加具体：

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

然后，在调用任何库方法时，可以使用此通用try / catch块直接捕获来自库的任何错误：

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

这是一个好习惯吗？

如果Exception被抽象化会好吗？

编辑：我的意思是，即使标记了异常类abstract，您仍然可以在全部捕获块中捕获它。将其抽象化只是禁止程序员抛出“超宽”异常的一种方法。通常，当您自愿引发异常时，您应该知道异常的类型以及发生原因。因此，强制抛出一个更具体的异常类型。

我不知道这样做的真正原因，在某种程度上，我同意防止抛出无限的异常是一件好事。

但是...在编写小型演示应用程序或概念验证代码时，我不想开始设计10个不同的异常子类，也不想花时间试图确定哪种情况是“最佳”异常情况类。我只想抛出Exception并传递一个解释细节的字符串。当它是一次性代码时，我不在乎这些事情，如果我被迫在乎这些事情，我要么创建自己的GenericException类，然后将其扔到任何地方，要么转移到其他工具/语言。对于某些项目，我同意正确创建相关的Exception子类很重要，但是并非所有项目都需要这样做。

可能性A：在逻辑上是正确的。

您是正确的，Microsoft和其他许多公司都不建议new Exception()出于多种原因而直接抛出该错误。

话虽如此，我们可以考虑学术上的理想，即Exception类层次结构的目的是定义一个缩小的效果，以便只能捕获最具体的例外。（即ArgumentNullException比窄ArgumentException）。

Exception类也不例外（双关语不是故意的）。它旨在成为可能的最广泛的例外，因为其范围无限广泛，因此几乎无法捕获“超级例外”。“异常” abstract在某种意义上并不是说异常不能作为一个实体单独存在。可以（尽管尚不能确定好的案例-见可能性B），因此应该是可公开构造的。

'abstract'关键字（从纯粹的学术意义上来说）仅适用于基类本身没有意义的情况，即FourLeggedAnimal。

考虑到所有这些，除了成为开发人员的麻烦之源之外，没有任何技术上的理由来上课。abstract

可能性B：设计锁定/他们不知道

如果MS使该类抽象化，那么如果他们改变主意，他们可能会遇到麻烦，因为该类对于语言的基础非常重要。他们已经厌倦了ApplicationException，因此可以预见的是，他们也预料到未来的建议也会有所变化。（请参阅http://blogs.msdn.com/b/kcwalina/archive/2006/06/23/644822.aspx）

可能还有其他原因（我想这可能与Reflection或其他一些技术原因有关），所以我将本帖子设为CW。