Cómo usar try catch para el manejo de excepciones es la mejor práctica

La mejor práctica es que el manejo de excepciones nunca debe ocultar los problemas. Esto significa que los bloques try-catch deben ser extremadamente raros.

Hay 3 circunstancias en las que usar un try-catch tiene sentido.

1. Siempre trate con excepciones conocidas lo más abajo posible. Sin embargo, si está esperando una excepción, por lo general es mejor hacer la prueba primero. Por ejemplo, las excepciones de análisis, formato y aritmética casi siempre son mejor manejadas por la lógica comprueba primero, en lugar de un try-catch específico.

2. Si necesita hacer algo en una excepción (por ejemplo, registrar o revertir una transacción), vuelva a lanzar la excepción.

3. Siempre trate con excepciones desconocidas tan alto como pueda-el código solo que debería consumir una excepción y no volver a lanzarla debería ser la interfaz de usuario o la API pública.

Supongamos que se está conectando a una API remota, aquí usted sabe que esperar ciertos errores (y tienen cosas que en esas circunstancias), por lo que este es el caso 1:

try 
{
    remoteApi.Connect()
}
catch(ApiConnectionSecurityException ex) 
{
    // User's security details have expired
    return false;
}

return true;

Tenga en cuenta que no se capturan otras excepciones, ya que no se esperan.

Ahora supongamos que está tratando de guardar algo en la base de datos. Tenemos que revertirlo si falla, así que tenemos el caso 2:

try
{
    DBConnection.Save();
}
catch
{
    // Roll back the DB changes so they aren't corrupted on ANY exception
    DBConnection.Rollback();

    // Re-throw the exception, it's critical that the user knows that it failed to save
    throw;
}

Tenga en cuenta que volvemos a lanzar la excepción-el código superior todavía necesita saber que algo ha fallado.

Finalmente tenemos la interfaz de usuario-aquí no queremos tener excepciones completamente desatendidas, pero tampoco queremos ocultarlas. Aquí tenemos un ejemplo del caso 3:

try
{
    // Do something
}
catch(Exception ex) 
{
    // Log exception for developers
    WriteException2LogFile(ex);

    // Display message to users
    DisplayWarningBox("An error has occurred, please contact support!");
}

Sin embargo, la mayoría de los marcos de API o UI tienen formas genéricas de hacer el caso 3. Por ejemplo ASP.Net tiene una pantalla de error amarilla que vuelca los detalles de la excepción, pero que se puede reemplazar con un mensaje más genérico en el entorno de producción. Seguir estos es una buena práctica porque le ahorra mucho código, pero también porque el registro de errores y la visualización deben ser config decisiones en lugar de codificadas.

Todo esto significa que el caso 1 (excepciones conocidas) y el caso 3 (manejo único de la interfaz de usuario) tienen mejores patrones (evitar el error esperado o el manejo de errores de mano a la interfaz de usuario).

Incluso el caso 2 puede ser reemplazado por mejores patrones, por ejemplo ámbitos de transacción (using bloques que revierten cualquier transacción no confirmada durante el bloque) hacen que sea más difícil para los desarrolladores obtener el patrón de mejores prácticas incorrecto.

Por ejemplo supongamos que tiene una gran escala ASP.Net solicitud. El registro de errores puede ser a través de ELMAH, la visualización de errores puede ser un YSoD informativo localmente y un agradable mensaje localizado en producción. Todas las conexiones de base de datos pueden ser a través de ámbitos de transacción y bloques using. No necesitas un solo bloque try-catch.

TL;DR: La mejor práctica es en realidad no usar bloques try-catch en absoluto.

Una excepción es un error de bloqueo .

En primer lugar, la mejor práctica debería ser no lanzar excepciones para cualquier tipo de error, a menos que sea un error de bloqueo.

Si el error es bloqueando, entonces lanza la excepción. Una vez que la excepción ya está lanzada, no hay necesidad de ocultarla porque es excepcional; informe al usuario sobre ella (debe reformatear toda la excepción a algo útil para el usuario en la interfaz de usuario).

Su trabajo como software el desarrollador debe tratar de evitar un caso excepcional donde algún parámetro o situación de tiempo de ejecución puede terminar en una excepción. Es decir, las excepciones no deben ser silenciadas, pero éstas deben ser evitadas.

Por ejemplo, si sabe que alguna entrada integer podría venir con un formato no válido, use int.TryParse en lugar de int.Parse. Hay muchos casos en los que puedes hacer esto en lugar de solo decir "si falla, simplemente lanza una excepción".

Lanzar excepciones es caro.

Si, después de todo, se lanza una excepción, en lugar de escribir la excepción en el registro una vez que se ha lanzado, una de las mejores prácticas es capturarla en un manejador de excepciones de primera oportunidad . Por ejemplo:

• ASP.NET: Global.asax Application_Error
• Otros: AppDomain.FirstChanceException event .

Mi postura es que los intentos/capturas locales son más adecuados para manejar casos especiales donde puede traducir un excepción en otro, o cuando quieras "silenciarlo" para un caso muy, muy, muy, muy, muy especial (un bug de biblioteca que lanza una excepción no relacionada que necesitas silenciar para solucionar todo el bug).

Para el resto de los casos:

• Trate de evitar excepciones.
• Si esto no es posible: manejadores de excepciones de primera oportunidad.
• O utilice un aspecto PostSharp (AOP).

Respondiendo a @thewhiteambit sobre algún comentario...

@thewhiteambit dijo:

Las excepciones no son Fatales-Errores, son Excepciones! A veces ni siquiera son Errores, pero considerarlos Fatales-Errores es completamente falsa comprensión de lo que son las excepciones.

En primer lugar, ¿cómo una excepción no puede ser incluso un error?

• No database connection => exception.
• Formato de cadena no válido para analizar a algún tipo = > exception
• Tratando de analizar JSON y while input no es realmente JSON = > excepción
• Argumento null mientras se esperaba objeto = > excepción
• Alguna biblioteca tiene un bug = > lanza una excepción inesperada
• Hay una conexión de socket y se desconecta. Luego intenta enviar un mensaje = > exception
• ...

Podríamos enumerar casos 1k de cuando se lanza una excepción, y después de todo, cualquiera de los casos posibles será un error.

Una excepción es un error, porque al final del día es un objeto que recoge información de diagnóstico has tiene un mensaje y sucede cuando algo sale mal.

Nadie lanzaría una excepción cuando no hay un caso excepcional. Las excepciones deben ser errores de bloqueo porque una vez que se lanzan, si no intenta caer en el use try/catch y excepciones para implementar control flow significan que su aplicación/servicio detendrá la operación que entró en un caso excepcional .

También, sugiero todos a comprobar el paradigma fail-fast publicado por Martin Fowler (y escrito por Jim Shore) . Así es como siempre entendí cómo manejar las excepciones, incluso antes de llegar a este documento hace algún tiempo.

[...] considéralos fatales: Los errores son una comprensión completamente falsa de lo que son las excepciones.

Por lo general, las excepciones cortan algunas operaciones fluyen y se manejan para convertirlas en errores comprensibles para el ser humano. Por lo tanto, parece que una excepción en realidad es un mejor paradigma para manejar casos de error y trabajar en ellos para evitar un bloqueo completo de la aplicación/servicio y notificar al usuario/consumidor que algo salió mal.

Más respuestas sobre las preocupaciones de @thewhiteambit

Por ejemplo, en caso de que falte una conexión a la base de datos, el programa podría excepcionalmente continuar con la escritura en un archivo local y enviar el cambia a la base de datos una vez que está disponible de nuevo. Su inválido String-To-Number casting podría ser tratado de analizar de nuevo con idioma-interpretación local en la excepción, como cuando intenta por defecto El idioma inglés para analizar("1,5") falla y lo intentas con alemán interpretación de nuevo, que está completamente bien porque usamos coma en lugar de apuntar como separador. Usted ve estas excepciones ni siquiera debe estar bloqueando, solo necesitan un poco de manejo de excepciones.

1. Si tu aplicación puede funcionar sin conexión sin conservar los datos en la base de datos, no debes usar excepciones, ya que implementar el flujo de control usando try/catch se considera como un anti-patrón. El trabajo fuera de línea es un posible caso de uso, por lo que implementa control flow para verificar si la base de datos es accesible o no, no espera hasta que sea inalcanzable.

2. El análisis también es un caso esperado (no UN CASO EXCEPCIONAL). Si esperas esto, ¡no usas excepciones para controlar el flujo!. Obtiene algunos metadatos del usuario para saber qué su cultura es y usted utiliza formateadores para esto! . NET admite este y otros entornos también, y se debe evitar una excepción porque el formato de números si espera un uso específico de la cultura de su aplicación/servicio.

Una Excepción no controlada generalmente se convierte en un Error, pero las Excepciones en sí no lo son codeproject.com/Articles/15921/Not-All-Exceptions-Are-Errors

Este artículo es solo una opinión o un punto de vista del autor.

Dado que Wikipedia también puede ser solo la opinión del autor (es) del artículo, yo no diría que es el dogma, pero mira lo que Codificación por excepción artículo dice en algún lugar en algún párrafo:

[...] Usando estas excepciones para manejar errores específicos que surgen a continuar el programa se llama coding by exception. Este anti-patrón puede degradar rápidamente el software en rendimiento y capacidad de mantenimiento.

También dice en algún lugar:

Uso incorrecto de la excepción

A menudo la codificación por excepción puede conducir a problemas adicionales en el software con uso incorrecto de excepciones. Además de usar excepción manejo para un problema único, el uso incorrecto de excepciones toma esto además mediante la ejecución de código incluso después de que se plantea la excepción. Este el método de programación pobre se asemeja al método goto en muchos programas idiomas, pero solo se produce después de un problema en el software es detectar.

Honestamente, creo que el software no se puede desarrollar no tome en serio los casos de uso. Si lo sabes...

• Su base de datos puede desconectarse...
• Se puede bloquear algún archivo...
• Es posible que algunos formatos no sean compatibles...
• Alguna validación de dominio puede fallar...
• Tu aplicación debería funcionar en modo sin conexión...
• cualquier caso de uso...

... no usarás excepciones para eso. Usted soportaría estos casos de uso usando el flujo de control regular.

Y si algún caso de uso inesperado no está cubierto, su código fallará rápidamente, porque lanzará una excepción. Correcto, porque una excepción es un caso excepcional .

Por otro lado, y finalmente, a veces cubrimos casos excepcionales lanzando excepciones esperadas, pero no las lanzamos para implementar control flow. Lo haces porque quieres notificar a las capas superiores que no admite algún caso de uso o que su código no funciona con algunos argumentos o datos/propiedades del entorno.

La única vez que debe preocuparse a sus usuarios por algo que sucedió en el código es si hay algo que pueden o necesitan hacer para evitar el problema. Si pueden cambiar los datos en un formulario, presione un botón o cambie la configuración de una aplicación para evitar el problema, hágaselo saber. Pero las advertencias o errores que el usuario no tiene capacidad para evitar solo les hace perder la confianza en su producto.

Las excepciones y los registros son para usted, el desarrollador, no para su usuario final. Comprensión de la lo correcto que debe hacer cuando captura cada excepción es mucho mejor que simplemente aplicar alguna regla de oro o confiar en una red de seguridad para toda la aplicación.

La codificación sin sentido es el ÚNICO tipo de codificación incorrecta. El hecho de que sientas que hay algo mejor que se puede hacer en esas situaciones muestra que estás invertido en una buena codificación, pero evita tratar de estampar alguna regla genérica en estas situaciones y entiende la razón de algo para lanzar en primer lugar y lo que puedes hacer para recuperar de ella.

Sé que esta es una vieja pregunta, pero nadie aquí mencionó el artículo de MSDN, y fue el documento que realmente lo aclaró para mí, MSDN tiene un muy buen documento sobre esto, debe capturar excepciones cuando las siguientes condiciones son ciertas:

• Tiene una buena comprensión de por qué se puede lanzar la excepción, y puede implementar una recuperación específica, como solicitar al usuario que ingrese un nuevo nombre de archivo cuando captura una excepción FileNotFoundException objeto.

• Puede crear y lanzar una excepción nueva y más específica.

int GetInt(int[] array, int index)
{
    try
    {
        return array[index];
    }
    catch(System.IndexOutOfRangeException e)
    {
        throw new System.ArgumentOutOfRangeException(
            "Parameter index is out of range.");
    }
}

• Desea manejar parcialmente una excepción antes de pasarla para un manejo adicional. En el siguiente ejemplo, se usa un bloque catch para agregar una entrada a un registro de errores antes de volver a lanzar la excepción.

    try
{
    // Try to access a resource.
}
catch (System.UnauthorizedAccessException e)
{
    // Call a custom error logging procedure.
    LogError(e);
    // Re-throw the error.
    throw;     
}

Sugiero leer toda la sección" Excepciones y Manejo de Excepciones " y también Las mejores Prácticas para Excepciones.

El mejor enfoque es el segundo (el que especifica el tipo de excepción). La ventaja de esto es que sabe que este tipo de excepción puede ocurrir en su código. Usted está manejando este tipo de excepción y puede reanudar. Si alguna otra excepción vino, entonces eso significa que algo está mal que le ayudará a encontrar errores en su código. La aplicación, finalmente, accidente, pero se llega a saber que hay algo que se perdió (bug) que necesita ser arreglado.

El segundo enfoque es bueno.

Si no desea mostrar el error y confundir al usuario de la aplicación al mostrar la excepción de tiempo de ejecución(es decir, error) que no está relacionada con ellos, simplemente registre el error y el equipo técnico puede buscar el problema y resolverlo.

try
{
  //do some work
}
catch(Exception exception)
{
   WriteException2LogFile(exception);//it will write the or log the error in a text file
}

Le recomiendo que opte por el segundo enfoque para toda su aplicación.

Dejar el bloque catch en blanco es lo peor que se puede hacer. Si hay un error, la mejor manera de manejarlo es:

1. Inicie sesión en file\database, etc..
2. Trate de arreglarlo sobre la marcha (tal vez tratando de forma alternativa de hacer esa operación)
3. Si no podemos arreglar eso, notifique al usuario que hay algún error y, por supuesto, abortar la operación

Para mí, manejar la excepción puede verse como una regla de negocios. Obviamente, el primer enfoque es inaceptable. El segundo es mejor y podría ser 100% correcto SI el contexto lo dice. Ahora, por ejemplo, está desarrollando un Addin de Outlook. Si addin lanza excepción no controlada, el usuario de Outlook ahora podría saberlo, ya que Outlook no se destruirá a sí mismo debido a un error de plugin. Y tienes dificultades para averiguar qué salió mal. Por lo tanto, el segundo enfoque en este caso, para mí, es correcto. Además de registrar la excepción, puede decidir mostrar un mensaje de error al usuario, lo considero una regla comercial.

La mejor práctica es lanzar una excepción cuando se produce el error. Porque se ha producido un error y no debe ocultarse.

Pero en la vida real puedes tener varias situaciones en las que quieras ocultar esto

1. Usted confía en el componente de terceros y desea continuar el programa en caso de error.
2. Tiene un caso de negocio que necesita continuar en caso de error

Debe tener en cuenta estas Pautas de Diseño para las Excepciones

• Lanzamiento de excepción
• Usando Tipos de Excepción Estándar
• Excepciones y Rendimiento

Https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/exceptions

El catch sin ningún argumento es simplemente comiéndose la excepción y no sirve de nada. ¿Qué pasa si ocurre un error fatal? No hay manera de saber qué pasó si usas Catch sin discusión.

Una declaración de captura debería capturar más excepciones específicas como FileNotFoundException y luego al final debería capturar Exception que capturaría cualquier otra excepción y las registraría.

A veces es necesario tratar las excepciones que no dicen nada a los usuarios.

Mi camino es:

• Para capturar excepciones no capturadas en el nivel de aplicación (es decir. en global.asax) para excepciones críticas (la aplicación no puede ser útil). Estas exepciones que no estoy cogiendo en el lugar. Solo tienes que registrarlos en el nivel de la aplicación y dejar que el sistema haga su trabajo.
• Captura "en el lugar" y muestra información útil al usuario (número incorrecto introducido, no se puede analizar).
• Coger en el lugar y no hacer nada en marginal problemas como "Voy a buscar información de actualización en segundo plano, pero el servicio no se está ejecutando".

Definitivamente no tiene que ser una buena práctica. ;-)

Con excepciones, intento lo siguiente:

Primero, cojo tipos especiales de excepciones como división por cero, operaciones IO, y así sucesivamente y escribo código de acuerdo con eso. Por ejemplo, una división por cero, dependiendo de la procedencia de los valores podría alertar al usuario (ejemplo una calculadora simple en que en un cálculo medio (no los argumentos) llega a una división por cero) o para tratar silenciosamente esa excepción, registrándola y continuar procesando.

Entonces trato de atrapar la excepciones restantes y registrarlas. Si es posible, permita la ejecución del código, de lo contrario, avise al usuario de que ha ocurrido un error y pídale que envíe un informe de error.

En código, algo como esto:

try{
    //Some code here
}
catch(DivideByZeroException dz){
    AlerUserDivideByZerohappened();
}
catch(Exception e){
    treatGeneralException(e);
}
finally{
    //if a IO operation here i close the hanging handlers for example
}