.NET 指南：异常与性能

抛出异常能够消极地影响到性能。关于常规的代码故障，你可以使用设计模式来把性能问题减到最少。本文描述了两个在异常可能严重地影响到性能时比较有用的设计模式。

不要使用错误码，因为这样做涉及到异常可能会消极地影响到性能。

使用设计来减轻性能问题。两个模式将在本文中被描述。

考虑可能在公共的开发情节中抛出异常来避免与异常相关的性能问题的成员的 Tester-Doer 模式。

Tester-Doer 模式把一个可能会抛出异常的调用划分成了两个部分：一个 Tester 与一个 Doer。Tester 为能够导致 Doer 抛出异常的状态来完成测试。这个测试只能够被插入在抛出异常的代码之前，因此保护了逆向的异常。

下列代码范例说明了这个模式的 Doer 部分。这个范例包含一个在它被传递 null 值（在 Visual Basic 中是 Nothing）的时候能够抛出一个异常的方法。如果这个方法经常被调用，那么它就会消极地影响到性能。

C#

public class Doer
{
    // 经常能够潜在地抛出异常的方法。
    public static void ProcessMessage(string message)
    {
        if (message == null)
        {
            throw new ArgumentNullException("message");
        }
    }
    // 其他方法...
}

下列代码范例说明了这个模式的 Tester 部分。这个方法在 Doer 将要抛出一个异常的时候使用一个测试来防止对于 Doer（ProcessMessage）的调用。

C#

public class Tester
{
    public static void TesterDoer(ICollection<string> messages)
    {
        foreach (string message in messages)
        {
            // 进行测试以确保调用不会导致异常。
            if (message != null)
            {
                Doer.ProcessMessage(message);
            }
        }
    }
}

注意：你必须解决潜在的紊乱条件，如果你在一个多线程的应用程序中使用这个模式并且测试还另外调用了一个易变的对象。那么一个线程就能够在测试之后但是在 Doer 被执行之前来改变易变对象的状态。因此使用线程同步技术来解决这些问题。

考虑可能在公共的开发情节中抛出异常来避免与异常相关的性能问题的成员的 TryParse 模式。

要实现 TryParse 模式，你就需要为完成一个能够在公共的开发情节中抛出异常的操作而提供两个不同的方法。第一个方法 X 只在适当的时候才进行操作并抛出异常。第二个方法 TryX 则并不会抛出异常，但是改为返回一个 Boolean 值来表示操作的成功或失败。任何通过对于 TryX 方法的成功调用而被返回的数据都是使用一个 out 参数（在 Visual Basic 中是 ByRef）而被返回的。Parse 方法与 TryParse 方法就是这个模式的范例。

为每个成员都使用 TryParse 模式来提供一个异常抛出成员。

只提供 TryX 方法几乎总是不太正确的设计，因为它需要理解 out 参数。同样，对于大部分公共的开发情节来说，异常所造成的性能影响并不是问题；你应该在大部分公共的开发情节中提供更加易于使用的方法。