Utilizzo di tipi di eccezioni standard
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.
In questa sezione vengono descritte le eccezioni standard fornite dal framework e i dettagli dell'utilizzo. L'elenco non è esaustivo. Per l'utilizzo di altri tipi di eccezioni framework, vedere la documentazione di riferimento di .NET Framework.
Eccezione e SystemException
❌ NON generare System.Exception o System.SystemException.
❌ NON intercettare System.Exception o System.SystemException nel codice del framework, a meno che non si intenda rigenerare.
❌ EVITARE di intercettare System.Exception o System.SystemException, ad eccezione dei gestori di eccezioni di primo livello.
ApplicationException
❌ NON generare o derivare da ApplicationException.
InvalidOperationException
✔️ GENERARE InvalidOperationException se l'oggetto si trova in uno stato non appropriato.
ArgumentException, ArgumentNullException e ArgumentOutOfRangeException
✔️ GENERARE ArgumentException o uno dei relativi sottotipi se vengono passati argomenti non validi a un membro. Preferire il tipo di eccezione più derivato, se applicabile.
✔️ IMPOSTARE la proprietà ParamName quando si genera una delle sottoclassi di ArgumentException.
Questa proprietà rappresenta il nome del parametro che ha causato la generazione dell'eccezione. Si noti che la proprietà può essere impostata usando uno degli overload del costruttore.
✔️ USARE value per il nome del parametro di valore implicito dei setter di proprietà.
NullReferenceException, IndexOutOfRangeException, e AccessViolationException
❌ NON consentire alle API chiamabili pubblicamente di generare in modo esplicito o implicito NullReferenceException, AccessViolationException o IndexOutOfRangeException. Queste eccezioni sono riservate e generate dal motore di esecuzione e nella maggior parte dei casi indicano un bug.
Eseguire il controllo degli argomenti per evitare di generare queste eccezioni. La generazione di queste eccezioni espone i dettagli di implementazione del metodo che potrebbero cambiare nel tempo.
StackOverflowException
❌ NON generare StackOverflowException in modo esplicito. L'eccezione deve essere generata in modo esplicito solo da CLR.
❌ NON intercettare StackOverflowException.
È quasi impossibile scrivere codice gestito che rimane coerente in presenza di overflow arbitrari dello stack. Le parti non gestite di CLR rimangono coerenti usando probe per spostare gli overflow dello stack in posizioni ben definite anziché eseguendo il backup dagli overflow arbitrari dello stack.
OutOfMemoryException
❌ NON generare OutOfMemoryException in modo esplicito. Questa eccezione deve essere generata solo dall'infrastruttura CLR.
ComException, SEHException e ExecutionEngineException
❌ NON generare in modo esplicito COMException, ExecutionEngineException e SEHException. Queste eccezioni devono essere generate solo dall'infrastruttura CLR.
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.