Cómo detectar excepciones

Question

Esta es mi primera aplicación que se ocupará de las excepciones correctamente. Es un servicio de WCF. Todo lo demás antes eran aplicaciones simples solo para mí. Tengo muy poco conocimiento sobre el manejo de excepciones en C#.

Tengo un código como el siguiente:

MembershipUser memUser = Membership.GetUser(username); 

DatabaseDataContext context = new DatabaseDataContext(); 
UserMembership user = UserMembership.getUserMembership(memUser); 
ItemsForUser itemUser = Helper.createItemForUser(ref item, memUser); 
Helper.setItemCreationInfo(ref item, user); 
context.Items.InsertOnSubmit(item); 
context.SubmitChanges(); 

En este código algunas excepciones pueden ocurrir. Como NullReferenceException por ejemplo. ¿Cómo sé qué objeto causó la excepción para poder saber qué hacer en la captura y qué devolver al cliente?

Answer 1

En general, no debe detectar excepciones.

Sé que esto suena extraño, pero el hecho es que solo debe detectar excepciones en las que realmente puede hacer, y por lo general no puede hacer nada acerca de las excepciones.

Las "excepciones" a esta regla tienen que ver con lo que significa "manejar" una excepción. En algunas aplicaciones, "manejar" la excepción significa iniciar sesión. En otros (ASP.NET, por ejemplo), es mejor que no maneje la excepción, porque el marco (ASP.NET Health Monitoring en este caso) lo registrará por usted.

En código controlado por eventos, como Windows Forms, encuentro que es necesario detectar excepciones dentro de los manejadores de eventos. Al menos en versiones anteriores de .NET, permitiendo que la excepción se propagara fuera de, por ejemplo, un evento de clic de botón produjo resultados desagradables. Normalmente capturo la excepción y la visualizo en un cuadro de diálogo.

En una aplicación de varios niveles, se podría capturar las excepciones en los límites de nivel, a continuación, volver a lanzar una nueva, de nivel específico de excepción:

try 
{ 
    // ... 
} 
catch (Exception ex) 
{ 
    throw new TierException("Some message", ex); 
} 

Otro caso de uso es para detectar la excepción, entonces lanzar una nueva excepción con más información en ella:

public int GetValueFromConfigurationFile(...) 
{ 
    const string configFileName = "..."; 
    try 
    { 
     // ... 
    } 
    catch (FileNotFoundException fEx) 
    { 
     throw new InvalidOperationException(
      String.Format("Can't find configuration file {0}", configFileName), 
      fEx); 
    } 
} 

en este caso, tienes que coger una excepción específica (FileNotFoundException), y proporcionando su información de la llamada otra manera no podrían saber: que el archivo no encontrado era un archivo de configuración.

El mensaje general es: - coger únicas excepciones que sabe cómo manejar - Captura la excepción más específica posible - siempre incluyen la excepción interna al crear una nueva excepción, para preservar la cadena de excepciones - Para volver a lanzar la excepción actual, use throw;, no throw ex;

Hay algunas más, y trataré de encontrar la referencia de las Pautas de diseño de Microsoft Framework.

P.S. Si alguien puede encontrar la pregunta de que este es un duplicado, siéntase libre de cerrarla como un duplicado. No me importa perder ningún representante de esto. Simplemente no pude encontrar el duplicado.

---

que debería tener acaba de publicar el enlace al "manejo de excepciones" tag wiki, donde dice:

Sin embargo, para el manejo de excepciones en el contexto de programas .NET, ver "Design Guidelines for Exceptions ".

Answer 2

Aunque WCF tiene mecanismos para pasar excepciones de servidor al cliente, probablemente valga la pena considerar si el usuario de su cliente realmente quiere ver en su cara excepciones típicamente complejas del lado del servidor.
En general, es mejor rastrear las expectativas del lado del servidor, y si desea acceder a eso de forma remota, utilice un registrador de seguimiento remoto. O tenga una API de seguimiento de texto único en su servidor para registrar las excepciones del servidor del lado del cliente de manera discreta.