异常类：何时从它派生，在C＃（.Net）中？

Question

我正在继续我的考试修订。

我所遇到的基本异常类的用法，我已经看到它在试卷也。

我的问题是，当你从基本异常类派生？

如果您希望自定义类引发具有更多有意义信息的异常，那么您可以创建一个自定义异常类，该类包含代表您的自定义类的确切数据，以及它被设计用于什么场景？

为什么我的自定义异常类从“ApplicationException的”或“抛出：SecurityException”或基地“异常”类派生？

我，我应该从Exception基类派生，而不是前两次的印象。

我的问题第二个是，你什么时候会从其他两个派生???是否有任何明确的 区分何时可以从这三个中的任何一个派生出来？假设没有其他人我有我错过了？

小幅更新：

从超越者这个问题几乎击中了要害。

---

*您应该使用哪个类来生成特定于应用程序的异常？

答：ApplicationException的类*

Answer 1

这是所有Design Guidelines文档中讨论。

Answer 2

一般情况下，你想从Exception类的，最接近你想抛出异常的类型推导。如果问题在于某些参数或参数已经通过而导致问题，请使用ArgumentException。如果您需要一些定制，请从ArgumentException继承。

根据我的经验，使用基本Exception的唯一两个原因是：1）当你需要一些自定义的异常，它完全不适合当前的异常模型之一或2）当一个方法理论上可以抛出一些例外情况，但你已经发现了你最有可能被抛出的那些。

通常情况下，我不从异常都继承。只需设置Message属性就足够了。

Answer 3

在我们最近的项目中，我们使用了一个基本的异常类。我们用它来获得以下功能：

• 所有异常需要大量的，所以定义为号的属性在基类中已完成
• 需要被格式化以同样的方式所有的异常信息，与数量，原因和类型。这个formform消息是在基类中完成的。

我们的基本异常类派生自ApplicationException。这可能是一个错误，有很多关于继承深度过多的问题的讨论。但是，我们对此没有任何问题。

考试小贴士：仔细阅读问题。祝你好运。

Answer 4

理想情况下，异常应该按照层次结构进行分组，以便如果代码要以同样的方式处理多个异常，它们将全部来自公共基类。如果基础可抛式类型是一个接口而不是一个类，那么这样的理想可能有点可以实现。然而，事实上，类的单继承限制严重限制了层次结构的有用性。

唯一一个异常层次结构倾向于成为一个有用的概念的时候，一个接口的实现或者一个类的新版本（被记录为抛出某些异常）希望允许代码区分更多不同的条件比那些例外情况报告的要多。在这种情况下，如果有一种方法抛出的异常不是来源于已记录的异常，那将是一个突破性的改变，因此必须抛出一个异常，该异常继承了最好描述以前未曾预料到的状况的记录。这相当难看，但异常处理机制并没有提供更好的选择。很不幸的是，诸如IEnumerator<T>.MoveNext()之类的东西没有被记录为抛出任何意味着“仅仅意味着”对不起 - 系统没有着火或什么的异常，而且我不知道有人改变了这个集合，但我无法推进到下一个项目，也没有如实说出枚举完成“，但他们没有。

除了需要抛出与现有代码兼容的异常情况之外，应用程序或库使用的异常来自公共基础可能会有帮助。它应该像YourApplicationNameException或YourLibraryNameException这样的东西，而不是其他任何东西都可以从中衍生出来的东西。像ApplicationException之类的东西是不好的，因为执行catch ApplicationException的代码不仅会得到它从该类型派生的异常，还会得到任何其他库从其派生的异常。