Errores comunes de programación in.Net al manejar excepciones? [cerrado]

Re-lanzar excepciones como esta:

try 
{ 
   // some code here
}
catch(Exception ex)
{
   // logging, etc
   throw ex;
}

Esto mata el seguimiento de la pila, haciendo que sea mucho menos utilizable. La manera correcta de repensar sería así:

try 
{ 
   // some code here
}
catch(Exception ex)
{
   // logging, etc
   throw;
}

Captura todas las excepciones cuando en muchos casos debe intentar capturar excepciones específicas:

try {
  // Do something.
} catch (Exception exc) {
  // Do something.
}

En lugar de:

try {
  // Do something.
} catch (IOException exc) {
  // Do something.
}

Las excepciones deben ordenarse de más específicas a menos.

Repensar una excepción con un mensaje sin sentido.

try
{
    ...
}
catch (Exception ex)
{
   throw new Exception("An error ocurred when saving database changes").
}

No creerás la frecuencia con la que veo código como este ejecutándose en producción.

Nadie está hablando de ver bloques de captura vacíos como estos....

 try{  
      //do something
    }
catch(SQLException sqex){  
        // do nothing  
    }

Tampoco utilice nunca el manejo de excepciones para crear flujos de métodos alternativos...

 try{  
     //do something  

 }catch(SQLException sqex){  

     //do something else  
 }

No usar using en IDisposable objetos:

File myFile = File.Open("some file");
callSomeMethodWhichThrowsException(myFile);
myFile.Close();

Miarchivo no se cierra hasta que miarchivo del finalizador se llama (el cual puede ser nunca) porque se produce una excepción antes de myFile.Close() fue llamado.

La manera correcta de hacer esto es

using(File myFile = File.Open("some file"))
{
    callSomeMethodWhichThrowsException(myFile);
}

Esto se traduce por el compilador en algo como:

File myFile = File.Open("some file");
try
{
    callSomeMethodWhichThrowsException(myFile);
}
finally
{
    if(myFile != null)
        myFile.Dispose(); //Dispose() calls Close()
}

Así que el archivo se cierra incluso ante excepciones.

Olvídese de establecer la excepción interna al repensar una excepción atrapada

try
{
    ...
}
catch (IOException ioException)
{
    throw new AppSpecificException("It was not possible to save exportation file.")
    // instead of
    throw new AppSpecificException("It was not possible to save exportation file.", ioException);
}

Cuando publiqué esta respuesta, me olvido de mencionar que siempre debemos considerar cuándo incluir excepciones internas o no debido a razones de seguridad. Como Eric Lippert señaló en otra respuesta para este tema, algunas excepciones pueden proporcionar información confidencial sobre los detalles de implementación del servidor. Por lo tanto, si el llamante que manejará la excepción no es de confianza, no lo es una buena idea incluir la información de la excepción interna.

Captura vacía:

//What's the point?
catch()
{}

Repensar:

//Exceptions are for *adding* detail up the stack
catch (Exception ex)
{throw ex;}

Asumir una excepción que cubre muchos escenarios era algo específico. Un escenario de la vida real era una aplicación web donde el manejo de excepciones siempre asumía que todos los errores eran tiempos de espera de la sesión y se registraban e informaban de todos los errores como tiempos de espera de la sesión.

Otro ejemplo:

try
{
     Insert(data);
}
catch (SqlException e)
{
   //oh this is a duplicate row, lets change to update
   Update(data);
}

Para registrar la Excepción.Mensaje en lugar de Excepción.toString ()

Muchas veces, veo el registro de código solo el mensaje de excepción, mientras que debería registrar el retorno del método toString. toString proporciona mucha más información sobre la excepción que el Mensaje. Incluye información como excepción interna y seguimiento de pila además del mensaje.

Tratando de atrapar OutOfMemoryException o StackOverflowException - estos conducen a un apagado del tiempo de ejecución, por lo tanto a la manera de atraparlos desde dentro del mismo Proceso (o incluso desde el CLR en su conjunto?)

OutOfMemoryException: La excepción que se lanza cuando no hay suficiente memoria para continuar la ejecución de un programa.

" A partir de la versión 2.0 de. NET Framework, un objeto StackOverflowException no puede ser capturado por un bloque try-catch y el proceso correspondiente se termina por defecto. En consecuencia, se aconseja a los usuarios escribir su código para detectar y evitar un desbordamiento de pila."

No se pueden detectar posibles excepciones dentro de un controlador de capturas. Esto puede hacer que la excepción equivocada se propague hacia arriba.

Por ejemplo:

try
{
    DoImportantWork();
}
catch
{
    Cleanup();        
    throw;
}

¿Qué sucede si Cleanup() lanza una excepción? No querrás ver una Excepción que apunte al método Cleanup() en este controlador de capturas. Quieres el error original. Puede intentar registrar el error de limpieza, pero incluso su código de registro necesita manejo de excepciones para evitar lanzar excepciones.

try
{
    DoImportantWork();
}
catch
{
    try
    {
        Cleanup();        
    }
    catch
    {
        // We did our best to clean up, and even that failed.
        // If you try to log this error, the logging may throw yet another Exception.
    }
    throw;
}

Incorrecto

try
{
   // Do something stupid
}
catch
{
   // ignore the resulting error because I'm lazy, and later spend
   // a week trying to figure out why my app is crashing all over
   // the place.
}

Mejor

try
{
    /// do something silly.
}
catch (InvalidOperationException ex)
{
    /// respond, or log it.
}
catch (Exception e)
{
    /// log it.
}

Usando excepciones para el control de flujo normal. Las excepciones deben ser excepcionales. Si es una operación buena / esperada, use valores de retorno, etc.