Desempenho e exceções

Gerar exceções pode afetar negativamente o desempenho. Para obter um código que rotineiramente falha, você pode usar padrões de design para minimizar problemas de desempenho. Este tópico descreve dois padrões de design que são úteis quando exceções podem afetar significativamente o desempenho.

Não use códigos de erro por causa das preocupações que exceções podem afetar negativamente o desempenho.

Use o design para minimizar os problemas de desempenho. Dois padrões são descritas neste tópico.

Considere o testador doer padrão para membros que podem lançar exceções em cenários comuns para evitar problemas de desempenho relacionados a exceções.

O padrão do testador doer divide uma telefonar que pode lançar exceções em duas partes: um testador e um doer. O testador executa um teste para o estado que pode causar doer lançar uma exceção. O teste é inserido exatamente antes do código que lança a exceção, assim se proteger contra a exceção.

O exemplo de código a seguir mostra o doer metade desse padrão. O exemplo contém um método que lança uma exceção quando ele é passado um null (Nothing no Visual Basic) valor. Se esse método for chamado com freqüência, ele poderia ter um impacto negativo sobre desempenho.

Public Class Doer

    ' Method that can potential throw exceptions often.
    Public Shared Sub ProcessMessage(ByVal message As String)
        If (message = Nothing) Then
            Throw New ArgumentNullException("message")
        End If
    End Sub

    ' Other methods...
End Class

public class Doer
{
    // Method that can potential throw exceptions often.
    public static void ProcessMessage(string message)
    {
        if (message == null)
        {
            throw new ArgumentNullException("message");
        }
    }
    // Other methods...
}

O exemplo de código a seguir mostra a parte do testador desse padrão. O método usa um teste para evitar que a telefonar para o doer (ProcessMessage) quando o doer deve lançar uma exceção.

Public Class Tester

    Public Shared Sub TesterDoer(ByVal messages As ICollection(Of String))
        For Each message As String In messages
            ' Test to ensure that the call 
            ' won't cause the exception.
            If (Not (message) Is Nothing) Then
                Doer.ProcessMessage(message)
            End If
        Next
    End Sub
End Class

public class Tester
{
    public static void TesterDoer(ICollection<string> messages)
    {
        foreach (string message in messages)
        {
            // Test to ensure that the call
            // won't cause the exception.
            if (message != null)
            {
                Doer.ProcessMessage(message);
            }
        }
    }
}

Observe que você deve endereço condições de corrida potencial se você usar esse padrão em um aplicativo multithreaded onde o teste envolve um objeto mutável. Um segmento pode alterar o estado do objeto mutável após o teste, mas antes de executa o doer. Use técnicas de sincronização de thread para solucionar esses problemas.

Considere o padrão de TryParse para membros que podem lançar exceções em cenários comuns para evitar problemas de desempenho relacionados a exceções.

Para implementar O TryParse padrão, você fornece dois métodos diferentes para executar uma operação que pode lançar exceções em cenários comuns. O primeiro método, X , realiza a operação e lança a exceção quando apropriado. O segundo método, TryX , lança a exceção, mas em vez disso, retorna um Boolean valor indicando êxito ou falha. Os dados retornados por uma telefonar bem-sucedida para TryX for retornados com um out (ByRef no Visual Basic) parâmetro. The Parse e TryParse os métodos são exemplos desse padrão.

Fornecem um membro de lançar a exceção para cada membro usando o padrão de TryParse.

Ele não é quase sempre design correto para fornecer somente o método TryX porque requer compreensão out parâmetros. Além disso, o impacto no desempenho de exceções não é um problema para cenários mais comuns; você deve fornecer métodos que são fáceis de usar em cenários mais comuns.

Partes direitos autorais 2005 Microsoft Corporation. Todos os direitos reservados.

Partes direitos autorais Addison-Wesley Corporation. Todos os direitos reservados.

Para obter mais informações sobre diretrizes de design, consulte a "diretrizes de design do estrutura: Catálogo de convenções, idiomas e padrões para bibliotecas do .NET reutilizável"Krzysztof Cwalina e Brad Abrams, publicado pela Addison-Wesley, 2005.

Consulte também

Outros recursos

Diretrizes de Design para desenvolvimento bibliotecas de classe

Diretrizes de design para exceções