Generazione di eccezioni
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.
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 è in grado di fare ciò per cui è stato progettato (ciò che il nome del membro implica). Ad esempio, se il metodo OpenFile 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.
✔️ SEGNALARE gli errori di esecuzione generando 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 Tester-Doer può comportare un sovraccarico delle prestazioni inaccettabile. In questi casi, deve essere considerato il cosiddetto modello 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.
✔️ DOCUMENTARE tutte le eccezioni generate dai membri chiamabili pubblicamente a causa di una violazione del contratto membro (anziché un errore di sistema), e considerarli 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 disporre di membri pubblici che possono generare o meno in base ad alcune opzioni.
❌ NON avere membri pubblici che restituiscono eccezioni come valore restituito o come parametro out.
La restituzione di eccezioni dalle API pubbliche, invece che 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 resi inlined. Lo spostamento dell'istruzione throw all'interno del generatore potrebbe consentire l'inlining del membro.
❌ NON generare 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 eseguire il debug.
❌ EVITARE di generare in modo esplicito eccezioni dai blocchi finally. Sono state generate in modo implicito eccezioni risultanti dalla chiamata di metodi che generano un'eccezione accettabile.
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.