Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Annotazioni
Questo contenuto viene ristampato con il permesso di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms e Pattern per Librerie .NET Riutilizzabili, 2a Edizione. Tale edizione è stata pubblicata nel 2008 e il libro è stato completamente rivisto nella terza edizione. Alcune informazioni in questa pagina potrebbero non essere aggiornate.
Una preoccupazione comune correlata alle eccezioni è che se le eccezioni vengono usate per il codice che fallisce regolarmente, le prestazioni dell'implementazione saranno inaccettabili. Si tratta di un problema reale. Quando un membro genera un'eccezione, le prestazioni possono essere 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 timore che le eccezioni possano influire negativamente sulle prestazioni.
Per migliorare le prestazioni, è possibile usare il modello di Tester-Doer o il modello di 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 ora il Add metodo 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 esito negativo spesso. 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 lanciata, come il metodo Add nel nostro esempio, definiamo il doer.
✔️ CONSIDERARE il modello Tester-Doer per i membri che potrebbero generare eccezioni, al fine di evitare problemi di prestazioni legati alle eccezioni in scenari comuni.
Modello Try-Parse
Per le API estremamente sensibili alle prestazioni, è consigliabile usare un modello ancora più veloce rispetto al modello di 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 Parse metodo che genera un'eccezione se l'analisi di una stringa ha esito negativo. Definisce anche un metodo corrispondente TryParse che tenta di analizzare, ma restituisce false se l'analisi non riesce e restituisce il risultato di un'analisi corretta usando un out parametro .
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, deve comunque lanciare un'eccezione corrispondente.
✔️ CONSIDERARE il modello di 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 di ritorno booleano per i metodi che seguono questo modello.
✔️ DO fornire un membro che lancia eccezioni per ogni altro membro utilizzando il modello Try-Parse.
© Porzioni 2005, 2009 Microsoft Corporation. Tutti i diritti riservati.
Ristampato dall'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms e Patterns for Reusable .NET Libraries, 2nd Edition di Krzysztof Cwalina e Brad Abrams, pubblicato il 22 ottobre 2008 da Addison-Wesley Professional come parte della Serie di sviluppo di Microsoft Windows.