摘要：
抛出异常能够消极地影响到性能。关于常规的代码故障，你可以使用设计模式来把性能问题减到最少。本文描述了两个在异常可能严重地影响到性能时比较有用的设计模式。 阅读全文
2007年2月3日 #
摘要：
下列指导方针有助于确保你的自定义异常是正确被设计的。 阅读全文
摘要：
下列指导方针为 .NET Framework 所提供的一些最常用的异常而描述了最佳的实践。关于 .NET Framework 所提供的完整的异常类列表，请参考：［.NET Framework 类库参考文档］。 阅读全文
摘要：
下列指导方针有助于确保你的异常消息是有意义的并且拥有正确的格式。 阅读全文
摘要：
要包装一个异常，你应该把它指定为新异常的内部异常然后抛出这个新的异常。这个实践应该只在原始异常不能够为接收者传达足够含意，或者该异常的调用堆栈是令接收者费解的或者是没有兴趣的情形之下才被使用。例如，考虑一个为了管理基于 XML 的配置文件而提供了功能的库。其中，配置文件管理器使用一个 XML 读取器来读取文件。如果某个配置文件拥有错误的格式，那么 XML 读取器就可以抛出一个为 XML 读取器和它所支持的类型而包括了一条消息和调用堆栈细节的异常，并且这个被抛出的异常对于应用程序的用户来说是毫无意义的。因此，在这种情节中就比较适合为配置文件管理器而包装 XML 读取器的异常并且重新抛出一个以真实自然的方式来表述问题的新异常。 阅读全文
摘要：
下列设计指导方针有助于确保你对现有的异常进行了适当的使用，并且在它们为你的库添加值的时候创建新的异常。 阅读全文
摘要：
异常会在成员无法成功地完成被设计的任务时被抛出。这表示出现了执行故障。例如，如果 Connect 方法不能够连接到被指定的远程终端，那么就会引起执行故障并且抛出一个异常。 阅读全文
2007年2月2日 #
摘要：
你可以通过密封成员的方式来限制开发者对你的库的扩展方式。在你密封一个类的时候，其他类就不能够从它那里继承。在你密封一个成员的时候，派生类就不能够重载该成员的实现。默认时你不应该密封任何类型和成员。密封可以防止针对于库类型和成员的定制，并且会影响一些开发者对于可用性的理解。另外，可扩展性是使用面向对象框架的一种基本利益。你应该不要随意地对这种利益进行约束。 阅读全文
摘要：
抽象化实现的基类是被设计成用来协助开发者实现抽象类和接口（抽象化）的类。它们为抽象化而提供了实现的细节并且在一些情况下它们是不需要进行继承就是能够被使用的。例如，Collection 能够被用来创建一个集合或者能够被继承来定义一个被强类型化的集合类。 阅读全文