Usar tipos de excepciones estándar
Nota:
Este contenido se ha copiado con permiso de Pearson Education, Inc. de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2ª edición. Esa edición se publicó en 2008 y el libro se ha revisado completamente en la tercera edición. Parte de la información de esta página puede estar obsoleta.
En esta sección se describen las excepciones estándar proporcionadas por Framework y los detalles de su uso. La lista no es exhaustiva. Vea la documentación de referencia de .NET Framework para el uso de otros tipos de excepción de Framework.
Excepción y SystemException
❌ NO inicie System.Exception ni System.SystemException.
❌ NO detecte System.Exception ni System.SystemException en el código de Framework, a menos que tenga previsto volver a iniciar.
❌ EVITE detectar System.Exception o System.SystemException, excepto en los controladores de excepciones de nivel superior.
ApplicationException
❌ NO inicie ni derive de ApplicationException.
InvalidOperationException
✔️ INICIE InvalidOperationException si el objeto está en un estado inadecuado.
ArgumentException, ArgumentNullException y ArgumentOutOfRangeException
✔️ INICIE ArgumentException o uno de sus subtipos si se pasan argumentos incorrectos a un miembro. Si procede, opte por el tipo de excepción más derivado.
✔️ ESTABLEZCA la propiedad ParamName al iniciar una de las subclases de ArgumentException.
Esta propiedad representa el nombre del parámetro que ha provocado el inicio de la excepción. Tenga en cuenta que la propiedad se puede establecer mediante una de las sobrecargas del constructor.
✔️ USE value para el nombre del parámetro de valor implícito de los establecedores de propiedades.
NullReferenceException, IndexOutOfRangeException y AccessViolationException
❌ NO permita que las API que se puedan llamar públicamente inicien NullReferenceException, AccessViolationException o IndexOutOfRangeException explícita o implícitamente. Estas excepciones están reservadas al motor de ejecución, que es el que las inicia y, en la mayoría de los casos, indican un error.
Realice una comprobación de argumentos para evitar iniciar estas excepciones. Al iniciar estas excepciones, se exponen los detalles de implementación del método, que podrían cambiar con el tiempo.
StackOverflowException
❌ NO inicie explícitamente StackOverflowException. La excepción solo debe iniciarse explícitamente mediante CLR.
❌ NO detecte StackOverflowException.
Es casi imposible escribir código administrado que siga siendo coherente en presencia de desbordamientos de pila arbitrarios. Las partes no administradas de CLR siguen manteniendo la coherencia mediante sondeos para mover los desbordamientos de pila a lugares bien definidos en lugar de salir de desbordamientos de pila arbitrarios.
OutOfMemoryException
❌ NO inicie explícitamente OutOfMemoryException. Esta excepción solo la inicia la infraestructura de CLR.
ComException, SEHException y ExecutionEngineException
❌ NO inicie explícitamente COMException, ExecutionEngineException y SEHException. Estas excepciones solo las inicia la infraestructura de CLR.
Portions © 2005, 2009 Microsoft Corporation. Todos los derechos reservados.
Material reimpreso con el consentimiento de Pearson Education, Inc. y extraído de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition (Instrucciones de diseño de .NET Framework: convenciones, expresiones y patrones para bibliotecas .NET reutilizables, 2.ª edición), de Krzysztof Cwalina y Brad Abrams, publicado el 22 de octubre de 2008 por Addison-Wesley Professional como parte de la serie Microsoft Windows Development.