Exceções e desempenho
Gerar exceções pode afetar negativamente o desempenho. Para códigos que rotineiramente falhar, você pode usar os padrões de design para minimizar problemas de desempenho. Este tópico descreve dois padrões de design são úteis quando as exceções podem afetar significativamente o desempenho.
Não use os códigos de erro devido a preocupações que exceções podem afetar negativamente o desempenho.
Use o design para atenuar os problemas de desempenho. Dois padrões são descritos neste tópico.
Considere o padrão do testador estar para membros que podem lançar exceções nos cenários comuns para evitar problemas de desempenho relacionados às exceções.
O padrão do testador estar divide uma chamada que pode lançar exceções em duas partes: um testador e um estar. O testador executa um teste para o estado que pode causar a estar a lançar uma exceção. O teste é inserido 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 a estar metade desse padrão. O exemplo contém um método que lança uma exceção quando ele é passado um null (Nothing em Visual Basic) valor. Se esse método for chamado com freqüência, ele poderá afetar negativamente o 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...
}
public ref class Doer
{
public:
// Method that can potential throw exceptions often.
static void ProcessMessage(String^ message)
{
if (message == nullptr)
{
throw gcnew ArgumentNullException("message");
}
}
// Other methods...
};
O exemplo de código a seguir mostra a parte de testador desse padrão. O método usa um teste para evitar que a chamada para a estar (ProcessMessage) quando a estar lançaria 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);
}
}
}
}
public ref class Tester
{
public:
static void TesterDoer(ICollection<String^>^ messages)
{
for each (String^ message in messages)
{
// Test to ensure that the call
// won't cause the exception.
if (message != nullptr)
{
Doer::ProcessMessage(message);
}
}
}
};
Observe que você deve abordar possíveis condições de corrida, 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 estar executa. 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 nos cenários comuns para evitar problemas de desempenho relacionados às exceções.
Para implementar a 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, o x, faz a operação e lança a exceção quando apropriado. O segundo método, TryX, não não lança a exceção, mas em vez disso, retorna um Boolean valor indicando o êxito ou falha. Todos os dados retornados por uma chamada bem-sucedida para TryX for retornados com um out (ByRef em Visual Basic) parâmetro. O Parse e TryParse métodos são exemplos deste padrão.
Fornece 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 ele requer uma compreensão out parâmetros. Além disso, o impacto de 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.
Portions Copyright 2005 Microsoft Corporation. Todos os direitos reservados.
Portions Copyright Addison-Wesley Corporation. Todos os direitos reservados.
Para obter mais informações sobre as diretrizes de design, consulte a "diretrizes de Design do Framework: Convenções, idiomas e padrões de reutilizável.Bibliotecas de rede" catálogo por Krzysztof Cwalina e Brad Abrams, publicado pela Addison-Wesley, 2005.
Consulte também
Outros recursos
Diretrizes de Design para desenvolvimento bibliotecas de classe