Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Nota:
Este contenido se reimprime con permiso de Pearson Education, Inc. de Directrices de diseño de frameworks: Convenciones, expresiones y patrones para bibliotecas reutilizables de .NET, 2ª edición. Esa edición fue publicada en 2008, y el libro ha sido totalmente revisado en la tercera edición. Parte de la información de esta página puede estar obsoleta.
Las instrucciones de generación de excepciones descritas en esta sección precisan que definamos bien el significado de "error de ejecución". El error de ejecución se produce siempre que un miembro no puede hacer lo que se diseñó para hacer (lo que implica el nombre del miembro). Por ejemplo, si el OpenFile método no puede devolver un identificador de archivo abierto al autor de la llamada, se consideraría un error de ejecución.
La mayoría de los desarrolladores se han familiarizado con el uso de excepciones para errores de uso, como divisiones por cero o referencias nulas. En framework, se usan excepciones para todas las condiciones de error, incluidos los errores de ejecución.
❌ NO devuelva códigos de error.
Las excepciones son los medios principales de notificar errores en marcos.
✔️ Informe de los errores de ejecución generando excepciones.
✔️ Considere la posibilidad de terminar el proceso llamando a System.Environment.FailFast (característica de .NET Framework 2.0) en lugar de producir una excepción si el código encuentra una situación en la que no es seguro para su ejecución posterior.
❌ NO use excepciones para el flujo de control normal, si es posible.
Excepto en el caso de potenciales errores del sistema y operaciones con posibles condiciones de carrera, los diseñadores de frameworks deben diseñar APIs para que los usuarios puedan escribir código que no produzca excepciones. Por ejemplo, puede proporcionar una manera de comprobar las condiciones previas antes de llamar a un miembro para que los usuarios puedan escribir código que no produzca excepciones.
El miembro usado para comprobar las condiciones previas de otro miembro se conoce a menudo como verificador, y el miembro que realmente realiza el trabajo se denomina ejecutor.
Hay casos en los que el patrón de Tester-Doer puede tener una sobrecarga de rendimiento inaceptable. En tales casos, se debe tener en cuenta el denominado patrón de Try-Parse (consulte Excepciones y rendimiento para obtener más información).
✔️ Tenga en cuenta las implicaciones de rendimiento que tiene generar excepciones. Es probable que las tasas de lanzamiento por encima de 100 por segundo afecten notablemente al rendimiento de la mayoría de las aplicaciones.
✔️ Documente todas las excepciones generadas por los miembros invocables públicamente debido a una infracción del contrato de miembros (en lugar de un error del sistema) y considérelas como parte del contrato.
Las excepciones que forman parte del contrato no deben cambiar de una versión a la siguiente (es decir, el tipo de excepción no debe cambiar y no se deben agregar nuevas excepciones).
❌ NO tenga miembros públicos que puedan iniciarse o no en función de alguna opción.
❌ NO tenga miembros públicos que devuelvan excepciones como el valor devuelto o un out parámetro.
Devolver excepciones de las API públicas en lugar de lanzarlas elimina muchos de los beneficios de los informes de errores basados en excepciones.
✔️ CONSIDERE la posibilidad de usar métodos del generador de excepciones.
Es habitual generar la misma excepción desde distintos lugares. Para evitar el sobredimensionamiento de código, use métodos auxiliares que creen excepciones e inicialicen sus propiedades.
Además, los miembros que generan excepciones no se insertan en línea. Mover la instrucción throw dentro del generador podría permitir que el miembro quede insertado.
❌ NO genere excepciones desde bloques de filtros de excepciones.
Cuando un filtro de excepciones genera una excepción, CLR detecta la excepción y el filtro devuelve false. Este comportamiento es indistinguible del que se produce cuando el filtro se ejecuta y devuelve false explícitamente, lo cual lo hace muy difícil de depurar.
❌ EVITE generar explícitamente excepciones de bloques Finally. Se aceptan las excepciones generadas implícitamente como consecuencia de llamar a métodos que se inician.
© Partes 2005, 2009 de Microsoft Corporation. Todos los derechos reservados.
Reimpreso con permiso de Pearson Education, Inc. de Framework Design Guidelines: Convenciones, Idiomas y Patrones para Bibliotecas .NET Reusables, 2ª Edición por Krzysztof Cwalina y Brad Abrams, publicado el 22 de octubre de 2008 por Addison-Wesley Professional como parte de la Serie Desarrollo de Microsoft Windows.