try practice net handling example error custom create catch best asp asp.net exception-handling

asp.net - practice - Manejo de excepciones en aplicaciones web.net



try catch asp (6)

Lo admito: no me molesto con demasiada manipulación de excepciones. Sé que debería hacer más, pero nunca puedo entender por dónde empezar y dónde parar. No estoy siendo flojo. Lejos de ahi. Es que estoy sobreexcitado con ambivalencia en el manejo de excepciones. Simplemente parece que hay un número infinito de lugares, incluso en la aplicación más pequeña donde se puede aplicar el manejo de excepciones y puede comenzar a sentirse como un exceso.

He sobrevivido con pruebas cuidadosas, validación y oración silenciosa, pero este es un accidente de mala programación a punto de suceder.

Entonces, ¿cuál es su excepción en el manejo de las mejores prácticas? En particular, ¿dónde están los lugares más obvios / críticos donde se debe aplicar el manejo de excepciones y dónde se deben considerar?

Perdón por la vaga pregunta, pero realmente quiero cerrar el libro sobre esto de una vez por todas.

Bueno, en el nivel más básico debería manejar el evento HttpApplication.Error en el archivo Global.asax. Esto debería registrar cualquier excepción que ocurra en un solo lugar para que pueda revisar el seguimiento de la pila de la excepción.

Aparte de este nivel básico, idealmente debería manejar excepciones donde sabe que puede recuperarse de ellas; por ejemplo, si espera que un archivo esté bloqueado, manejar una excepción IOException y reportar el error al usuario sería una buena idea.

Comience con un manejador de excepción global como http://code.google.com/p/elmah/ .

Entonces, la pregunta se reduce a qué tipo de aplicación estás escribiendo y qué tipo de experiencia de usuario necesitas proporcionar. Cuanto más rica sea la experiencia del usuario, mejor será el manejo de excepciones que desees proporcionar.

Como ejemplo, considere un sitio de alojamiento de fotos que tenga cuotas de disco, límites de tamaño de archivo, límites de dimensión de imagen, etc. Para cada error, simplemente puede devolver "Se ha producido un error. Inténtelo de nuevo". O podría entrar en el manejo de errores detallados:

  • "Su archivo es demasiado grande. Maximum filesizes es 5mb".
  • "Su imagen es grande. Las dimensiones máximas son 1200x1200".
  • "Tu álbum está lleno. La capacidad máxima de almacenamiento es de 1 gb".
  • "Hubo un error con su carga. Nuestros hatersters no están contentos. Vuelva más tarde".

etcétera etcétera.

No existe un tamaño único para el manejo de excepciones.

El equipo de Patterns & Practices de Microsoft hizo un buen trabajo al incorporar las mejores prácticas de gestión de excepciones en Enterprise Library Exception Handling Application Block

Si no utiliza Enterprise Library, le recomiendo que lea su documentación. El equipo de P & P describe los escenarios comunes y las mejores prácticas para el manejo de excepciones.

Para empezar, recomiendo leer los siguientes artículos:

Artículos específicos de ASP.NET:

La regla de oro con manejo de excepciones es:

"Solo atrapa lo que sabes cómo manejar"

He visto demasiados bloqueos de prueba donde la captura no hace más que volver a lanzar la excepción. Esto no agrega ningún valor. El hecho de que llame a un método que tiene el potencial de lanzar una excepción no significa que tenga que lidiar con la posible excepción en el código de llamada. A menudo es perfectamente aceptable dejar que las excepciones se propaguen por la pila de llamadas a otro código que sí sabe qué hacer. En algunos casos, es válido permitir que las excepciones se propaguen hasta la capa de la interfaz del usuario y luego atrapar y mostrar el mensaje al usuario. Es posible que ningún código esté mejor ubicado para saber cómo manejar la situación y el usuario debe decidir el curso de acción.

Podría ser más sobre el manejo de excepciones en general que ASP.NET específico, pero:

  • Intente detectar excepciones tan cerca de la causa como sea posible para que pueda registrar (registrar) tanta información sobre la excepción como sea posible.
  • Incluya alguna forma de capturar todas, controlador de excepciones de último recurso en los puntos de entrada a su programa. En ASP.NET, este podría ser el controlador de error de nivel de aplicación.
  • Si no sabe cómo manejar "correctamente" una excepción, permita que suba hasta el controlador catch all, donde puede tratarlo como una excepción "inesperada".
  • Use los métodos Try ***** en .NET para cosas como acceder a un diccionario. Esto ayuda a evitar grandes problemas de rendimiento (el manejo de excepciones es relativamente lento) si se lanzan múltiples excepciones en, por ejemplo, un bucle.
  • No utilice el manejo de excepciones para controlar la lógica normal de su programa, por ejemplo, salir de un bucle a través de una declaración de lanzamiento.

Te recomiendo que comiences añadiendo una buena página de error que capte todas las excepciones e imprima un mensaje ligeramente menos hostil para el usuario. Asegúrese de registrar todos los detalles disponibles de la excepción y revisar eso. Hazle saber al usuario que lo has hecho y dale un enlace a una página que probablemente funcionará.

Ahora, use ese registro para detectar dónde se debe implementar el manejo especial de excepciones. Recuerde que no sirve de nada capturar una excepción a menos que planee hacer algo con ella. Si tiene la página anterior en su lugar, no sirve de nada capturar excepciones de base de datos individualmente en todas las operaciones de base de datos, a menos que tenga alguna forma específica de recuperación en ese punto específico.

Recuerde: Lo único peor que no captar excepciones es atraparlos y no hacer nada. Esto solo ocultará los problemas reales.