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.
Le linee guida per la generazione di eccezioni descritte in questa sezione richiedono una buona definizione del significato dell'errore di esecuzione. L'errore di esecuzione si verifica ogni volta che un membro non può eseguire le operazioni che è stato progettato per eseguire (cosa implica il nome del membro). Ad esempio, se il OpenFile metodo non può restituire un handle di file aperto al chiamante, verrebbe considerato un errore di esecuzione.
La maggior parte degli sviluppatori ha familiarità con l'uso di eccezioni per gli errori di utilizzo, ad esempio divisione per zero o riferimenti Null. In Framework le eccezioni vengono usate per tutte le condizioni di errore, inclusi gli errori di esecuzione.
❌ NON restituire codici di errore.
Le eccezioni sono i principali mezzi per segnalare gli errori nei framework.
✔️ SEGNALA errori di esecuzione lanciando eccezioni.
✔️ CONSIDERARE di terminare il processo chiamando System.Environment.FailFast (funzionalità .NET Framework 2.0) invece di generare un'eccezione se il codice rileva una situazione in cui non è sicuro per un'ulteriore esecuzione.
❌ NON usare eccezioni per il normale flusso di controllo, se possibile.
Ad eccezione di errori di sistema e operazioni con potenziali race condition, i progettisti di framework devono progettare API in modo che gli utenti possano scrivere codice che non generi eccezioni. Ad esempio, è possibile fornire un modo per controllare le precondizioni prima di chiamare un membro in modo che gli utenti possano scrivere codice che non genera eccezioni.
Il membro usato per controllare le precondizioni di un altro membro viene spesso definito tester e il membro che effettivamente esegue il lavoro viene chiamato doer.
Esistono casi in cui il modello di Tester-Doer può avere un sovraccarico delle prestazioni inaccettabile. In questi casi, è consigliabile considerare il cosiddetto modello di Try-Parse (vedere Eccezioni e prestazioni per altre informazioni).
✔️ CONSIDERARE le implicazioni sulle prestazioni della generazione di eccezioni. È probabile che i tassi di lancio superiori a 100 al secondo influiscano notevolmente sulle prestazioni della maggior parte delle applicazioni.
✔️ Documenta tutte le eccezioni generate dai membri chiamabili pubblicamente a causa di una violazione del contratto del membro (anziché un errore di sistema) e trattale come parte del contratto.
Le eccezioni che fanno parte del contratto non devono passare da una versione a quella successiva( ad esempio, il tipo di eccezione non deve cambiare e non devono essere aggiunte nuove eccezioni).
❌ NON avere membri pubblici che possano potenzialmente lanciare eccezioni a seconda di qualche opzione.
❌ NON dispongono di membri pubblici che restituiscono eccezioni come valore restituito o come out parametro.
La restituzione di eccezioni dalle API pubbliche invece di generarle elimina molti dei vantaggi della segnalazione degli errori basata sulle eccezioni.
✔️ PRENDERE IN CONSIDERAZIONE l'uso di metodi di generatore di eccezioni.
È comune generare la stessa eccezione da posizioni diverse. Per evitare il bloat del codice, usare metodi helper che creano eccezioni e inizializzano le relative proprietà.
Inoltre, i membri che generano eccezioni non vengono inseriti inlinea. Lo spostamento dell'istruzione throw all'interno del builder potrebbe consentire l'inlining del membro.
❌ NON lanciare eccezioni dai blocchi di filtro delle eccezioni.
Quando un filtro eccezioni genera un'eccezione, l'eccezione viene intercettata da CLR e il filtro restituisce false. Questo comportamento è indistinguibile dall'esecuzione del filtro e dalla restituzione di false in modo esplicito ed è quindi molto difficile effettuare il debugging.
❌ EVITARE di generare in modo esplicito eccezioni dai blocchi finally. Eccezioni generate implicitamente a causa della chiamata di metodi che lanciano eccezioni sono accettabili.
© 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.