Pregunta

Lo admito:No me molesto con demasiado manejo de excepciones.Sé que debería hacer más, pero nunca consigo entender por dónde empezar y dónde parar.No estoy siendo vago.Lejos de ahi.Es que estoy abrumado por la ambivalencia en el manejo de excepciones.Simplemente parece que hay una cantidad aparentemente infinita de lugares, incluso en la aplicación más pequeña, donde se puede aplicar el manejo de excepciones y puede comenzar a parecer excesivo.

Me las he arreglado con pruebas cuidadosas, validaciones y oración silenciosa, pero este es un grave accidente de programación que está a punto de suceder.

Entonces, ¿cuáles son sus mejores prácticas en el manejo de excepciones?En particular, ¿cuáles son los lugares más obvios/críticos donde se debe aplicar el manejo de excepciones y dónde se debe considerar?

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

¿Fue útil?

Solución

Microsoft Equipo de Patrones y Prácticas hizo un buen trabajo al incorporar las mejores prácticas de gestión de excepciones en Enterprise Library Bloque de aplicación de manejo de excepciones

Evento si no usaría Enterprise Library, yo altamente Te recomiendo que leas su documentación.El equipo de P&P describe escenarios comunes y mejores prácticas para el manejo de excepciones.

Para comenzar, recomiendo leer los siguientes artículos:

Artículos específicos de ASP.NET:

Otros consejos

La regla de oro con el manejo de excepciones es:

"Sólo atrapa lo que sabes manejar"

He visto demasiados bloques try-catch donde catch no hace más que volver a lanzar la excepción.Esto no añade ningún valor.Sólo porque llames a un método que tiene el potencial de generar una excepción no significa que tengas que lidiar con la posible excepción en el código de llamada.A menudo es perfectamente aceptable permitir que las excepciones se propaguen por la pila de llamadas hasta algún otro código que sí sepa qué hacer.En algunos casos, es válido permitir que las excepciones se propaguen hasta la capa de la interfaz de usuario y luego capturen y muestren el mensaje al usuario.Puede ser que ningún código esté en la mejor posición para saber cómo manejar la situación y el usuario deba decidir el curso de acción.

Le recomiendo que comience agregando una buena página de error que detecte todas las excepciones e imprima un mensaje un poco menos hostil para el usuario.Asegúrese de registrar todos los detalles disponibles de la excepción y revíselos.Informe al usuario que ha hecho esto y proporciónele un enlace a una página que (probablemente) funcionará.

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

Recordar:Lo único peor que no detectar excepciones es detectarlas y no hacer nada.Esto sólo ocultará los problemas reales.

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

  • Trate de detectar excepciones lo más cerca posible de la causa como sea posible para que puede registrar (registrar) tanta información sobre la excepción como sea posible.
  • Incluir alguna forma de cajón de sastre, al final resort en el puntos de entrada a su programa.En ASP.NET esto podría ser el Controlador de errores de nivel de aplicación.
  • Si no sabe cómo manejar "correctamente" una excepción, déjela aparecer en el controlador catch all, donde podrá tratarla como una excepción "inesperada".
  • Uso de los métodos Try***** en .NET para cosas como acceder a un Diccionario.Esto ayuda a evitar problemas de rendimiento (excepción manejo es relativamente lento) si Lanzar varias excepciones en, por ejemplo, un bucle.
  • No use el manejo de excepciones para controlar la lógica normal de su programa, por ejemplo,Salir desde un bucle a través de una declaración de lanzamiento.

Comience con un controlador de excepciones 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 brindar.Cuanto más rica sea la experiencia del usuario, mejor manejo de excepciones querrá proporcionar.

Como ejemplo, considere un sitio de alojamiento de fotografías que tiene 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éntalo de nuevo".O podría entrar en el manejo detallado de errores:

  • "Su archivo es demasiado grande.Máximo El tamaño de los archivos es de 5 MB".
  • "Tu imagen es demasiado grande.Las dimensiones máximas son: 1200x1200".
  • "Tu álbum está lleno.La capacidad máxima de almacenamiento es de 1gb".
  • "Hubo un error con su subir.Nuestros hámsters no están contentos.Por favor regresa más tarde."

etc.etc.

No existe una solución única para el manejo de excepciones.

Bueno, en un nivel muy básico deberías 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, lo ideal sería manejar excepciones de las que sepa que puede recuperarse; por ejemplo, si espera que un archivo esté bloqueado, entonces sería una buena idea manejar la IOException e informar el error al usuario.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top