Eccezioni e prestazioni
Nota
Questo contenuto viene ristampato con l'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms and Patterns for Reusable .NET Libraries, 2nd Edition. Tale edizione è stata pubblicata nel 2008 e il libro è stato completamente rivisto nella terza edizione. Alcune informazioni in questa pagina potrebbero non essere aggiornate.
Un problema comune correlato alle eccezioni è che se vengono usate eccezioni per il codice che fallisce abitualmente, le prestazioni dell'implementazione saranno inaccettabili. Si tratta di un problema reale. Quando un membro genera un'eccezione, le prestazioni possono essere di ordini di grandezza più lente. Tuttavia, è possibile ottenere buone prestazioni rispettando rigorosamente le linee guida sulle eccezioni che non consentono l'uso di codici di errore. Due modelli descritti in questa sezione suggeriscono modi per eseguire questa operazione.
❌ NON usare codici di errore per evitare che le eccezioni possano influire negativamente sulle prestazioni.
Per migliorare le prestazioni, è possibile usare il modello Tester-Doer o il modello Try-Parse, descritto nelle due sezioni successive.
Modello Tester-Doer
A volte le prestazioni di un membro che genera eccezioni possono essere migliorate suddividendo il membro in due. Esaminiamo’il metodo Add dell'interfaccia ICollection<T>.
ICollection<int> numbers = ...
numbers.Add(1);
Il metodo Add genera un'eccezione se la raccolta è di sola lettura. Può trattarsi di un problema di prestazioni negli scenari in cui la chiamata al metodo dovrebbe avere spesso esito negativo. Uno dei modi per attenuare il problema consiste nel verificare se la raccolta è scrivibile prima di provare ad aggiungere un valore.
ICollection<int> numbers = ...
...
if (!numbers.IsReadOnly)
{
numbers.Add(1);
}
Il membro usato per testare una condizione, che in questo esempio è la proprietà IsReadOnly, viene definita tester. Il membro usato per eseguire un'operazione potenzialmente generata, il metodo Add nell'esempio, viene definito doer.
✔️ CONSIDERARE il modello Tester-Doer per i membri che potrebbero generare eccezioni in scenari comuni per evitare problemi di prestazioni correlati alle eccezioni.
Modello Try-Parse
Per le API estremamente sensibili alle prestazioni, è consigliabile usare un modello ancora più veloce rispetto al modello Tester-Doer descritto nella sezione precedente. Il modello richiede di modificare il nome del membro per fare in modo che un test case ben definito faccia parte della semantica del membro. Ad esempio, DateTime definisce un metodo Parse che genera un'eccezione se l'analisi di una stringa ha esito negativo. Definisce anche un metodo TryParse corrispondente che tenta di analizzare, ma restituisce false se l'analisi non riesce e restituisce il risultato di un'analisi corretta usando un parametro out.
public struct DateTime
{
public static DateTime Parse(string dateTime)
{
...
}
public static bool TryParse(string dateTime, out DateTime result)
{
...
}
}
Quando si usa questo modello, è importante definire la funzionalità try in termini rigorosi. Se il membro non riesce per qualsiasi motivo diverso dal tentativo ben definito, il membro deve comunque generare un'eccezione corrispondente.
✔️ CONSIDERARE il modello Try-Parse per i membri che potrebbero generare eccezioni in scenari comuni per evitare problemi di prestazioni correlati alle eccezioni.
✔️ USARE il prefisso "Try" e il tipo restituito booleano per i metodi che implementano questo modello.
✔️ SPECIFICARE un membro che genera eccezioni per ogni membro che usa il modello Try-Parse.
Parti protette da copyright © 2005, 2009 Microsoft Corporation. Tutti i diritti sono riservati.
Ristampato con l'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2a edizione di Krzysztof Cwalina and Brad Abrams, pubblicato il 22 ottobre 2008 da Addison-Wesley Professional nella collana Microsoft Windows Development Series.