c# - mvc - catch exception asp net core

¿Cuál es la mejor manera de manejar las excepciones y cómo lidiar con ellas en asp.net

Question

En primer lugar, ya estoy familiarizado con la sintaxis simple de manejo de excepciones, pero estoy preguntando sobre el mejor lugar, el mejor momento y la mejor manera de lidiar con ellos.

Estoy construyendo una aplicación N-Layered. así que creo que el DAL en algún momento generará algunos errores que manejar ... y acabo de enterarme de la clase SqlException, ¿cuál es el problema con esa clase? Una vez vi un código que maneja la SqlException y luego maneja Exception.

Después de conocer la práctica y dónde voy a manejarlos, tengo la intención de crear un método para conectarme a la base de datos y registrar los errores en una base de datos para poder solucionarlo, pero aún no sé qué información debo recoger para permitirme identificar toda la situación!

Pensé que el manejo de excepciones no era gran cosa. pero de vez en cuando leía algunos consejos extraños -que nunca entendí- sobre los comentarios de las preguntas pero nadie podía responderme, ¡ya que eran algunas preguntas muy antiguas!

"No solo capturas explícitamente las excepciones"

"el código que usan las capas superiores en su aplicación siempre debe arrojar excepciones y nunca preocuparse por cómo lidiar con ellas".

EDITAR

¿Qué Page_Error evento Page_Error y Application_Error ... Vi que son una buena práctica para el manejo de errores

Answer 1

Creo que lo que estás preguntando aquí es una estrategia de manejo de errores / excepciones para cualquier aplicación.

Creo que incluye:

Dónde : todos los lugares en los que cree que se puede producir una excepción o que necesitan más supervisión, como llamadas de base de datos, llamadas de servicio externo, uso de matrices, análisis de entrada de usuario, tipo de transmisión, etc.

Cómo - Todas las capas de alto nivel deben lanzar la excepción y debe capturarse en el punto de entrada y procesarse para comprender la causa raíz. Por lo general, usted hace esto en Application_Error () donde detecta la excepción y la registra para la resolución de problemas. Cómo se registra una excepción depende de usted. Un archivo de registro o registro controlado por DB es una opción basada en sus requisitos y recursos disponibles.

Answer 2

Eche un vistazo a Elmah. Es un registrador para asp.net. Representa todos los errores en una página de resumen agradable.

http://code.google.com/p/elmah/

La mejor forma de manejar excepciones es en la capa específica a la que se aplican. Si se trata de una voladura de restricción, por ejemplo, 2 usuarios con el mismo nombre, debe dejar que suba a la interfaz de usuario y alertar al usuario.

Lo mismo ocurre con cualquier violación de las reglas comerciales. Esos deben pasar a la interfaz de usuario para que el usuario final sepa qué salió mal.

Un error de Conectividad SQL se maneja mejor en el DAL ... etc.

Answer 3

El cómo / cuándo / dónde atrapar las excepciones puede depender de lo que trate de hacer exactamente, es difícil dar una respuesta exacta de todas las respuestas correctas.

En cuanto a sus preguntas específicas,

Acabo de enterarme de la clase SqlException, ¿cuál es el trato con esa clase? Una vez vi un código que maneja la SqlException y luego maneja Exception.

Es una buena práctica manejar la excepción específica que cree que puede ocurrir, si no está seguro de qué tipo es esta excepción, puede simplemente ''Excepción'', si desea que ocurra algo específico en una ''SQLException'' y que ocurra algo más con ''Exception ''entonces, ciertamente, no hay nada de malo en escribir código que maneje ambos.

"No solo capturas explícitamente las excepciones"

Creo que esto se refiere a un código como este

try 
{
   int i = 1/0;
} 
catch(Exception e)
{
  //do nothing
}

Esta excepción será atrapada, pero nunca sabrás que sucedió, por lo tanto, esta no es una buena idea, y la persona que usa el código se rascará la cabeza en cuanto a lo que está sucediendo.

Answer 4

El manejo de excepciones es un gran problema, y ​​no es fácil diseñar una buena estrategia para eso.

Antes que nada, algunas reglas generales:

• Las excepciones se producen cuando el código de ejecución es completamente incapaz de continuar, por lo que tal vez trató de manejar algunas excepciones internas pero finalmente falló. Piensa en la conexión TCP: si llega un paquete dañado, es una excepción, pero el protocolo TCP puede manejarlo. Si hay demasiados dañados, se lanza una excepción de E / S o zócalo
• Las excepciones no siempre se pueden manejar . En casi todos los casos, cuando obtiene una excepción de las capas subyacentes, no puede ejecutar el código correctivo. Si su aplicación depende de un DB y está fuera de línea, cuando obtiene la excepción, solo puede mostrar un mensaje de error
• Las excepciones pueden ser inesperadas y pueden revelar defectos de diseño o implementación. Por ejemplo, un error de implementación puede ser la situación en la que tiene una base de datos redundante, pero cuando no puede conectarse al espejo de pulsera no intenta con la segunda

Para el tercer punto, es importante registrar excepciones y analizar registros periódicamente para encontrar cualquier situación extraña. Entonces, comencemos con la respuesta concreta.

Ante todo

piense en "manejar" la excepción. Cuando escriba cada línea de código, piense en los posibles problemas que pueden impedir que se complete y piense en las posibles acciones correctivas . si alguno es posible Un mensaje de error no es una buena forma de manejo, es la última estrategia.

No comience a escribir try-catch (Exception), pero prefiere excepciones específicas. Si necesita analizar cadenas a números, etc., espere FormatException , si necesita convertir de Object a su tipo espera InvalidCastException

Cuando escribes capas de nivel inferior

no dudes en lanzar excepciones !! No hagas como lo hacen muchas personas, es decir. return null o usa (como ANSI C) un valor de retorno booleano y parámetros de referencia. Las excepciones están ahí para eso. Si puede manejar una excepción (es decir, no encuentra un archivo local pero sabe que tiene una copia de seguridad remota, maneje FileNotFoundException llamando al espejo remoto, pero si aún no se puede conectar, y finalmente arroje), hágalo. y trate de reanudar el cálculo, pero si no puede, entonces arroje. Y no olvide lanzar la excepción interna, si está presente, porque es útil para iniciar sesión en la capa más alta.

Básicamente, ¡aún puedes decidir lanzar una excepción por tu cuenta incluso si no capturas ninguna! ¡Y esto es muy recomendable especialmente cuando los parámetros de función no son válidos!

Otra buena opción es todavía iniciar sesión en las capas subyacentes. De hecho, desea iniciar sesión sin importar si se produce una excepción.

Cuando inicias sesión

recuerde dar una severidad adecuada a los mensajes. Si encuentra a través de un código que su base de datos está fuera de línea, esa no es una excepción inesperada. Aún registre como un error, pero no se preocupe por los errores de código cuando investigue los registros. En cambio, si detecta una excepción que su código no puede reconocer (una NullReferenceException es un ejemplo clásico), inicie sesión con la mayor gravedad, es decir. fatal, para darle la máxima prioridad!

Una buena estrategia para ASP.NET

seguramente se puede basar en el método Page.OnError . Si tiene una clase de página base para todas las páginas de su sitio, definitivamente debe anular ese método. En ese método, primero debe registrar su excepción.

Tampoco debe abusar de los bloques try-catch (Exception), porque si no atrapa una excepción que no puede manejar con catch, tendrá que manejarla a través de OnError.

Cuando ejecute dicho método, no piense inmediatamente en Server.RemoveError() . Puede preferir tener una página HTML estática para el error HTTP 500 (que se desencadena cuando una excepción no controlada se propaga al tiempo de ejecución de ASP.NET) que muestra un mensaje de cortesía para el usuario.

Brevemente

1. No dudes en throw capas subyacentes si ocurre algo extraño
2. Como dice su consejo, no maneje las excepciones que no puede manejar (si detecta una excepción que no puede manejar, vuelva a lanzarla)
3. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡INICIAR SESIÓN!!!!!!!!!!!!!!!!!
4. ¡No divulgue detalles de excepción a los usuarios finales en un sitio web público, nunca! De forma predeterminada, ASP.NET evita que eso ocurra, pero aún puede usar OnError para imprimir el seguimiento de la pila
5. Utilice OnError o Application_Error como único punto central para manejar todas las excepciones inesperadas
6. Examine periódicamente los registros contra los mensajes de error / fatales para encontrar problemas con su código, luego piense en mantener / depurar / corregirlo

Answer 5

IMO, aparte de circunstancias extremadamente raras, solo uso el manejo de excepciones para código relacionado con E / S donde hay interacciones con servicios y sistemas de archivos cuya funcionalidad y mantenimiento escapan al control de mis aplicaciones.

Siempre he considerado el uso de las declaraciones try / catch para manipular la lógica (flujo de control) en un programa de la misma manera que si la instrucción / else funcionara como una práctica extremadamente mala. Las excepciones más comunes se pueden evitar si usa las herramientas a mano correctamente.