Effective C# 原则44：创建应用程序特定的异常类

核心提示： 这远不及使用多个catch语句有吸引力，这是很脆弱的代码：如果只是常规的修改了名字，Effective C# 原则44：创建应用程序特定的异常类(2)，它就被破坏了，如果你移动了造成错误的函数调用，对于这个基类你不用添加太多的功能，对于不同的异常类，放到了一个共享的工具函数中，它也被破坏了

这远不及使用多个catch语句有吸引力，这是很脆弱的代码：如果只是常规的修改了名字，它就被破坏了。如果你移动了造成错误的函数调用，放到了一个共享的工具函数中，它也被破坏了。在更深一层的堆栈上发生异常，就会使这样的结构变得更脆弱。

在深入讨论这一话题前，让我先附带说明两个不能做承诺的事情。首先，异常并不能处理你所遇到的所有异常。这并不是一个稳固指导方法，但我喜欢为错误条件抛出异常，这些错误条件如果不立即处理或者报告，可能会在后期产生更严重的问题。例如，数据库里的数据完整性的错误，就应该生产一个异常。这个问题如果忽略就只会越发严重。而像在写入用户的窗口位置失败时，不太像是在后来会产生一系列的问题。返回一个错误代码来指示失败就足够了。

其次，写一个抛出(throw)语句并不意味会在这个时间创建一个新的异常类。我推荐创建更多的异常，而不是只有少数几个常规的自然异常：很从人好像在抛出异常时只对System.Exception情有独钟。可惜只只能提供最小的帮助信息来处理调用代码。相反，考虑创建一些必须的异常类，可以让调用代码明白是什么情况，而且提供了最好的机会来恢复它。

再说一遍：实际上要创建不同的异常类的原则，而且唯一原因是让你的用户在写catch语句来处理错误时更简单。查看分析这些错误条件，看哪些可以放一类里，成为一个可以恢复错误的行为，然后创建指定的异常类来处理这些行为。你的应用程序可以从一个文件或者目录丢失的错误中恢复过来吗？它还可以从安全权限不足的情况下恢复吗？网络资源丢失又会怎样呢？对于这种遇到不同的错误，可能要采取不同的恢复机制时，你应该为不同的行为创建新的异常类。

因此，现在你应该创建你自己的异常类了。当你创建一个异常类时，你有很多责任要完成。你应该总是从System.ApplicationException类派生你的异常类，而不是System.Exception类。对于这个基类你不用添加太多的功能。对于不同的异常类，它已经具有可以在不同的catch语句中处理的能力了。