11
Esistono eccezioni definite in .NET Framework che non dovrei inserire nel mio codice o che è una cattiva pratica? Dovrei scrivere il mio?In C#, ci sono delle eccezioni built-in che non dovrei usare?
A
risposta
22
Non si deve lanciare alcuna eccezione che viene generata automaticamente dal CLR a causa di errori dell'utente. Per esempio
- StackOverflowException
- NullReferenceException
- AccessViolationException
- ecc ...
Il motivo è di farlo crea confusione per le persone che chiedono il vostro API. Gli utenti dovrebbero essere in grado di distinguere tra eccezioni generate attivamente da un'API e eccezioni che non vengono lanciate attivamente (generate da CLR).
Il motivo è che l'eccezione generata attivamente rappresenta generalmente uno stato noto in un'API. Se chiamo un'API e lancia una ArgumentException, ho una ragionevole aspettativa che l'oggetto dato sia in buono stato. Riconosceva una situazione potenzialmente negativa e lo rendeva conto attivamente. D'altra parte, se lancia una NullRefrenceException, è un'indicazione che l'API ha riscontrato un errore sconosciuto ed è ora in uno stato inaffidabile.
Un altro motivo minore è che queste eccezioni si comportano in modo diverso quando vengono generate dal codice utente in contrapposizione al CLR. Ad esempio è possibile catturare una StackOverflowException se lanciata dal codice utente, ma non se è lanciata dal CLR.
EDIT risposta al commento di Michael
Inoltre, non dovrebbe gettare Exception, ApplicationException o SystemException direttamente. Questi tipi di eccezioni sono troppo generici per fornire informazioni significative al codice che chiama la tua API. È vero che puoi inserire un messaggio molto descrittivo nel parametro del messaggio. Ma non è semplice o manutenibile per rilevare un'eccezione basata su un messaggio. È molto meglio prenderlo in base al tipo.
FxCop regola su questo argomento: http://msdn.microsoft.com/en-us/library/ms182338(VS.80).aspx
0
ci sono diversi eccezione già definito per voi. Cerca sempre di usare questi Exceptions prima di lanciare il tuo
+0
@downvoters: ti preghiamo di spiegare i tuoi downvotes, o sono inutili – dfa
9
La maggior parte delle classi di eccezioni nel framework non sono pensate per il riutilizzo poiché solitamente sono create per segnalare alcuni errori specifici del Framework. Come quelli mentioned by @JaredPar, vengono utilizzati dal framework per indicare determinati stati nel framework.
Ci sono letteralmente decine, forse centinaia, eccezioni nel framework, quindi IMO è più utile elencare quelli che utilizziamo .Nella parte superiore della mia testa, questi sono quelli che uso attivamente:
- ArgumentException, ArgumentNullException e ArgumentOutOfRangeException
- InvalidOperationException
- NotSupportedException
- NotImplementedException
Per le altre condizioni di errore nel codice utente , la migliore pratica è creare le tue classi di eccezioni.
+0
Concordato. E infatti, non dovresti lanciare un'eccezione in cui un metodo Framework lo lanci invece. ** I.e ** ** Se incapsuli una pila
2
Microsoft ha affermato a un certo punto che i programmatori non ereditano direttamente da Exception, ma utilizzano ApplicationException come classe base. Non sono sicuro se questa opinione sia ancora valida, sebbene ...
E se esiste già un'eccezione predefinita che copre la tua esatta condizione di errore (come "NullReferenceException", o "InvalidArgumentException" ecc.) - con tutti i mezzi, lancia quelli invece di reinventarli nel tuo codice personale.
Marc
+2
Sì, la posizione su ApplicationException è cambiata. Si consiglia ora di non derivare da quella classe: http://blogs.msdn.com/brada/archive/2004/03/25/96251.aspx – JaredPar
+1
Tra .NET 2.0 e 3.0 penso. Il consiglio per derivare da ApplicationException in .NET 2.0 esiste ancora su MSDN per 2.0 e precedenti - http://msdn.microsoft.com/en-us/library/system.applicationexception(VS.80).aspx. Per 3.0 è cambiato - http://msdn.microsoft.com/en-us/library/system.applicationexception(VS.85).aspx – BlackWasp
0
La linea Design Guidelines for Exceptions contiene il consiglio principio (vedi in particolare this pagina).
Il libro "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition" ha più dettagli e più discussioni su questo argomento.
3
@Michael In realtà c'è una situazione in cui si consiglia di lanciare una NullReferenceException: Se il primo parametro (il "questo" parametro) di un metodo di estensione è nullo. È necessario farlo in modo che le variabili nulle si comportino come previsto.
Problemi correlati
- 1. Ci sono motivi per cui dovrei/non dovrei usare ObjectId nelle URL del mio RESTful
- 2. Dovrei imparare a implementare OOP in C? Ci sono progetti che usano OOP in C?
- 3. Ci sono molte eccezioni in Bad design in Java?
- 4. Che cosa gacutil.exe dovrei usare?
- 5. gestore delle eccezioni non chiamata in C
- 6. Toolkit Gui, che dovrei usare?
- 7. Che Game Engine dovrei usare?
- 8. Gestione delle eccezioni C++ nei codici C
- 9. Quale approccio delle funzioni dovrei usare
- 10. Che cosa dovrei # include usare 'htonl'?
- 11. C#: gestione delle eccezioni in chiamata ricorsiva
- 12. Perché non dovrei usare sempre i tipi nullable in C#
- 13. Quando dovrei usare l'attributo in C#?
- 14. Gestione delle eccezioni C#, quale clausola catch da usare?
- 15. Registrazione C#. Cosa dovrei usare?
- 16. C# Quando dovrei usare List e quando dovrei usare l'arraylist?
- 17. Quale classe wrapper in C++ dovrei usare per la gestione automatizzata delle risorse?
- 18. C++ gestione delle eccezioni
- 19. Ci sono delle euristiche di padding CSS che posso seguire?
- 20. Che gui toolkit dovrei usare con Pygame?
- 21. Gestione delle eccezioni CPU in C++
- 22. Ci sono ragioni per non usare lombok con Android Studio
- 23. Dovrei usare ora C++ 11 lambda?
- 24. Quando dovrei usare AutoMapper e quando non lo sono
- 25. Quando dovrei usare C++ anziché SQL?
- 26. Che cosa dovrei usare IronPython IDE?
- 27. C++ - quando dovrei usare un membro pointer in una classe
- 28. In C# ci sono oggetti Lambda Expressions?
- 29. Perché non ci sono raccolte simultanee in C#?
- 30. Perché non dovrei usare Unity?
Accetto, fatta eccezione per NullReferenceException ... a meno che non si comporti diversamente, penso che sia valido lanciare questo quando qualcuno passa null come parametro che non può essere nullo. – Eddie
@Eddie si dovrebbe usare ArgumentNullException invece di NullReferenceException. E sì, fa un comportamento diverso. Avrà un codice HRESULT differente. – JaredPar
È necessario aggiungere "Eccezione" all'elenco. L'unico modo per prenderlo sarebbe quello di ingoiare tutte le eccezioni. – Michael