注释
此内容由 Pearson Education， Inc. 的许可从 框架设计指南：可重用 .NET 库的约定、习惯和模式（第 2 版）重新打印。 该版于2008年出版，此后该书已于 第三版全面修订。 此页上的一些信息可能已过期。
与异常相关的一个常见问题是，如果异常用于经常失败的代码，则实现的性能将是不能接受的。 这是一个合理的担忧。 当一个成员引发一个异常时，其性能可能会慢几个数量级。 但是，在严格遵循禁止使用错误代码的异常准则的同时，可以实现良好的性能。 本节中所述的两种模式建议执行此作的方法。
❌ 请勿使用错误代码，因为担心异常可能会对性能造成负面影响。
为了提高性能，可以使用 Tester-Doer 模式或 Try-Parse 模式，如下两节中所述。
“测试者-执行者”模式
有时，异常引发成员的性能可以通过将该成员分成两部分来提高。 让我们看看 Add 接口的 ICollection<T> 方法。
ICollection<int> numbers = ...
numbers.Add(1);
如果集合是只读的，则 Add 方法引发。 在方法调用预期经常失败的情况下，这可以是性能问题。 缓解问题的方法之一是在尝试添加值之前测试集合是否可写。
ICollection<int> numbers = ...
...
if (!numbers.IsReadOnly)
{
numbers.Add(1);
}
用于测试条件的成员（在本示例中为属性 IsReadOnly）称为测试人员。 用于执行潜在引发操作的成员（在本示例中为 Add 方法）被称为执行者。
✔️ 请考虑对可能在常见场景中引发异常的成员使用“测试者-执行者”模式，以避免与异常相关的性能问题。
“尝试-分析”模式
对于极其性能敏感的 API，应使用比前一部分中描述的 Tester-Doer 模式更快的模式。 该模式要求调整成员名称，从而使定义完善的测试用例成为成员语义的一部分。 例如， DateTime 定义在 Parse 分析字符串失败时引发异常的方法。 它还定义了一个相应的 TryParse 方法，该方法尝试解析，如果解析失败，则返回 false，如果成功，则返回一个使用 out 参数的解析结果。
public struct DateTime
{
public static DateTime Parse(string dateTime)
{
...
}
public static bool TryParse(string dateTime, out DateTime result)
{
...
}
}
使用此模式时，必须严格定义 try 功能。 如果成员由于定义完善的“尝试”功能以外的任何原因失败，该成员仍必须引发相应的异常。
✔️ 请考虑对可能在常见场景中引发异常的成员使用“尝试-分析”模式，以避免与异常相关的性能问题。
✔️ 对于实现此模式的方法，请务必使用前缀“Try”和布尔返回类型。
✔️ 请务必使用“尝试-分析”模式为每个成员提供一个异常引发成员。
部分内容 © 2005, 2009 Microsoft 公司。 保留所有权利。
获得皮尔逊教育公司许可后重印自 框架设计准则：可重用 .NET 库的约定、习惯和模式 ，由 Krzysztof Cwalina 和 Brad Abrams 编写，并作为微软 Windows 开发系列中的出版物之一，于 2008 年 10 月 22 日由 Addison-Wesley Professional 出版。