Generazione di eccezioni

Nota

Questo contenuto viene ristampato dall'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms e 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 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.

❌ DO NOT restituisce codici di errore.

Le eccezioni sono i principali mezzi per segnalare gli errori nei framework.

✔️ DO segnala 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, il cosiddetto modello Try-Parse deve essere considerato (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.

✔️ Do documenta tutte le eccezioni generate dai membri chiamabili pubblicamente a causa di una violazione del contratto membro (anziché un errore di sistema) e li considera 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).

❌ DO NOT have public members that can throw or not based on some option.

❌ 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 inlinedi. Lo spostamento dell'istruzione throw all'interno del generatore potrebbe consentire l'inlining del membro.

❌ DO NOT genera 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 la 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.

Vedi anche