Eccezioni e prestazioni
La generazione di eccezioni può influire negativamente sulle prestazioni. Per il codice che genera frequentemente errori, è possibile utilizzare modelli di progettazione che consentano di ridurre al minimo i problemi relativi alle prestazioni. In questo argomento vengono descritti due modelli di progettazione che risultano utili quando le eccezioni possono avere un impatto significativo sulle prestazioni.
Non utilizzare codici di errore perché si teme che le eccezioni possano influire negativamente sulle prestazioni.
Per limitare i problemi relativi alle prestazioni, è opportuno intervenire a livello di progettazione. In questo argomento vengono descritti due modelli possibili.
Prendere in considerazione il modello Tester-Agente per i membri che possono generare eccezioni in scenari comuni al fine di evitare problemi di prestazioni correlati alle eccezioni.
Il modello di Tester-Persona server dell'agente durante una chiamata che potrebbe generare eccezioni in due parti: un tester e una persona dell'agente. Il Tester esegue un test relativo allo stato che può determinare la generazione di un'eccezione da parte dell'Agente. Il test viene inserito immediatamente prima del codice che determina la generazione dell'eccezione, in modo da evitare che questa venga generata.
Nell'esempio di codice riportato di seguito viene illustrata la parte relativa all'Agente di questo modello. Nell'esempio è incluso un metodo che genera un'eccezione quando viene passato un valore null (Nothing in Visual Basic). Se chiamato di frequente, questo metodo può avere un impatto negativo sulle prestazioni.
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...
};
Nell'esempio di codice riportato di seguito viene illustrata la parte relativa al Tester di questo modello. Il metodo utilizza un test per impedire la chiamata all'Agente (ProcessMessage) quando verrebbe generata un'eccezione.
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);
}
}
}
};
Si noti che è necessario risolvere potenziali race condition se si utilizza questo modello in un'applicazione multithread in cui viene sottoposto a test un oggetto modificabile. Un thread può cambiare lo stato di tale oggetto dopo il test ma prima dell'esecuzione dell'Agente. Per risolvere questi problemi, utilizzare le tecniche di sincronizzazione dei thread.
Prendere in considerazione il modello TryParse per i membri che possono generare eccezioni in scenari comuni al fine di evitare problemi di prestazioni correlati alle eccezioni.
Per implementare il modello TryParse è necessario fornire due diversi metodi per l'esecuzione di un'operazione che possono generare eccezioni in scenari comuni. Il primo metodo, X, esegue l'operazione e genera l'eccezione quando opportuno. Il secondo metodo, TryX, non genera l'eccezione, ma restituisce un valore Boolean che indica l'esito positivo o negativo dell'operazione. I dati risultanti da una chiamata con esito positivo a TryX vengono restituiti mediante un parametro out (ByRef in Visual Basic). I metodi Parse e TryParse costituiscono due esempi di questo modello.
Fornire un membro per la generazione di eccezioni per ciascun membro per il quale viene utilizzato il modello TryParse.
Non è consigliabile in genere fornire soltanto il metodo TryX poiché richiede la comprensione dei parametri out. Inoltre, l'impatto delle eccezioni sulle prestazioni non rappresenta un problema negli scenari più comuni, in cui è in genere opportuno fornire metodi facili da utilizzare.
Portions Copyright 2005 Microsoft Corporation. Tutti i diritti riservati.
Portions Copyright Addison-Wesley Corporation. Tutti i diritti riservati.
Per ulteriori informazioni sulle linee guida di progettazione, vedere “le linee guida di progettazione di Framework: Idiomi convenzioni, e modelli per libro raccolte riutilizzabili .NET„ di Krzysztof Cwalina e brad Abrams, emessi da Addison-Wesley, 2005.
Vedere anche
Altre risorse
Linee guida di progettazione per lo sviluppo di librerie di classi