Mejores prácticas para atrapar y volver a lanzar excepciones .NET

Question

¿Cuáles son las mejores prácticas a tener en cuenta al capturar excepciones y volver a lanzarlas? Quiero asegurarme de que el Exception objeto InnerException y el seguimiento de la pila se conservan. ¿Hay alguna diferencia entre los siguientes bloques de código en la forma en que manejan esto?

try 
{ 
    //some code 
} 
catch (Exception ex) 
{ 
    throw ex; 
} 

Vs:

try 
{ 
    //some code 
} 
catch 
{ 
    throw; 
} 

Answer 1

La manera de preservar la traza de la pila es a través del uso de la throw; Este es válida, así

try { 
    // something that bombs here 
} catch (Exception ex) 
{ 
    throw; 
} 

throw ex; es básicamente como una excepción de ese punto, por lo que el seguimiento de la pila solo iría a donde está emitiendo la declaración throw ex;.

Mike también es correcto, suponiendo que la excepción le permite pasar una excepción (que se recomienda).

Karl Seguin tiene un great write up on exception handling en su foundations of programming e-book también, que es una gran lectura.

Editar: Enlace de trabajo a Foundations of Programming pdf. Simplemente busque en el texto "excepción".

Answer 2

Cuando usted throw ex, esencialmente está lanzando una nueva excepción, y se perderá la información de seguimiento de la pila original. throw es el método preferido.

Answer 3

La regla de oro es evitar la captura y el lanzamiento del objeto básico Exception. Esto te obliga a ser un poco más inteligente acerca de las excepciones; en otras palabras, debe tener una captura explícita para un SqlException para que su código de manejo no haga algo incorrecto con un NullReferenceException.

En el mundo real, sin embargo, la captura y extracción de madera la excepción de base es también una buena práctica, pero no se olvide de caminar toda la cosa para conseguir cualquier InnerExceptions que podría tener.

Answer 4

Si se lanza una nueva excepción con la excepción inicial va a conservar la traza inicial pila también ..

try{ 
} 
catch(Exception ex){ 
    throw new MoreDescriptiveException("here is what was happening", ex); 
} 

Answer 5

definitivamente usaría:

try 
{ 
    //some code 
} 
catch 
{ 
    //you should totally do something here, but feel free to rethrow 
    //if you need to send the exception up the stack. 
    throw; 
} 

que preservará su pila.

Answer 6

También puede utilizar:

try 
{ 
// Dangerous code 
} 
finally 
{ 
// clean up, or do nothing 
} 

Y cualquier excepción lanzada burbuja voluntad hasta el siguiente nivel que se ocupa de ellos.

Answer 7

Siempre debe usar "throw;" para volver a lanzar las excepciones en.NET,

remitir este, http://weblogs.asp.net/bhouse/archive/2004/11/30/272297.aspx

Básicamente MSIL (CIL) tiene dos instrucciones - "tirar" y "volver a lanzar":

• C# 's "tiro ex"; se compila en el "lanzamiento" de MSIL
• C# 's "throw"; - ¡en "re-lanzamiento" de MSIL!

Básicamente puedo ver el motivo por el que "throw ex" anula el seguimiento de la pila.

Answer 8

FYI Acabo de probar esto y el seguimiento de pila reportado por 'throw;' no es un rastro de pila completamente correcto. Ejemplo:

private void foo() 
    { 
     try 
     { 
      bar(3); 
      bar(2); 
      bar(1); 
      bar(0); 
     } 
     catch(DivideByZeroException) 
     { 
      //log message and rethrow... 
      throw; 
     } 
    } 

    private void bar(int b) 
    { 
     int a = 1; 
     int c = a/b; // Generate divide by zero exception. 
    } 

Los puntos de rastreo de pila para el origen de la excepción correctamente (número de línea reportado), pero el número de línea reportado para foo() es la línea de la banda; declaración, por lo tanto, no puede decir cuál de las llamadas a bar() causó la excepción.

Answer 9

Algunas personas realmente omitieron un punto muy importante: 'throw' y 'throw ex' pueden hacer lo mismo pero no le dan una información crucial, que es la línea donde ocurrió la excepción.

Considere el siguiente código:

static void Main(string[] args) 
{ 
    try 
    { 
     TestMe(); 
    } 
    catch (Exception ex) 
    { 
     string ss = ex.ToString(); 
    } 
} 

static void TestMe() 
{ 
    try 
    { 
     //here's some code that will generate an exception - line #17 
    } 
    catch (Exception ex) 
    { 
     //throw new ApplicationException(ex.ToString()); 
     throw ex; // line# 22 
    } 
} 

Cuando lo haga, ya sea un 'tiro' o 'tiro ex', se obtiene el seguimiento de la pila pero la línea # va a ser # 22, de modo que no puede entender qué línea exactamente arrojaba la excepción (a menos que tenga solo 1 o pocas líneas de código en el bloque try). Para obtener la línea 17 esperada en su excepción, deberá lanzar una nueva excepción con el seguimiento original de la pila de excepción.

Answer 10

En realidad, hay algunas situaciones en las que la declaración throw no conservará la información de StackTrace. Por ejemplo, en el código de abajo:

try 
{ 
    int i = 0; 
    int j = 12/i; // Line 47 
    int k = j + 1; 
} 
catch 
{ 
    // do something 
    // ... 
    throw; // Line 54 
} 

El StackTrace indicará que la línea 54 produce la excepción, aunque se planteó en línea 47.

Unhandled Exception: System.DivideByZeroException: Attempted to divide by zero. 
    at Program.WithThrowIncomplete() in Program.cs:line 54 
    at Program.Main(String[] args) in Program.cs:line 106 

En situaciones como la que se ha descrito anteriormente, hay dos opciones para la preseve StackTrace el original:

Llamando al Exception.InternalPreserveStackTrace

Como es un método privado, tiene que ser invocada mediante el uso de la reflexión:

private static void PreserveStackTrace(Exception exception) 
{ 
    MethodInfo preserveStackTrace = typeof(Exception).GetMethod("InternalPreserveStackTrace", 
    BindingFlags.Instance | BindingFlags.NonPublic); 
    preserveStackTrace.Invoke(exception, null); 
} 

I tiene una desventaja de depender de un método privado para preservar la información StackTrace. Se puede cambiar en futuras versiones de .NET Framework. El ejemplo de código anterior y la solución propuesta a continuación se extrajeron del Fabrice MARGUERIE weblog.

Calling Exception.SetObjectData

La técnica más adelante fue sugerido por Anton Tykhyy como respuesta a la pregunta In C#, how can I rethrow InnerException without losing stack trace.

static void PreserveStackTrace (Exception e) 
{ 
    var ctx = new StreamingContext (StreamingContextStates.CrossAppDomain) ; 
    var mgr = new ObjectManager  (null, ctx) ; 
    var si = new SerializationInfo (e.GetType(), new FormatterConverter()) ; 

    e.GetObjectData (si, ctx) ; 
    mgr.RegisterObject (e, 1, si) ; // prepare for SetObjectData 
    mgr.DoFixups  ()   ; // ObjectManager calls SetObjectData 

    // voila, e is unmodified save for _remoteStackTraceString 
} 

Aunque, tiene la ventaja de confiar en los métodos públicos sólo sino que también depende de la constructora siguiente excepción (que algunas excepciones desarrolladas por 3 partes no implementan):

protected Exception(
    SerializationInfo info, 
    StreamingContext context 
) 

En mi situación , Tuve que elegir el primer enfoque, porque las excepciones planteadas por una biblioteca de terceros que estaba usando no implementaron este constructor.

Answer 11

Nadie ha explicado la diferencia entre ExceptionDispatchInfo.Capture(ex).Throw() y throw, así que aquí está. Sin embargo, algunas personas han notado el problema con throw.

La forma completa de volver a lanzar una excepción atrapada es usar ExceptionDispatchInfo.Capture(ex).Throw() (solo disponible desde .Net 4.5).

A continuación están los casos necesarios para probar esto:

1.

void CallingMethod() 
{ 
    //try 
    { 
     throw new Exception("TEST"); 
    } 
    //catch 
    { 
    // throw; 
    } 
} 

2.

void CallingMethod() 
{ 
    try 
    { 
     throw new Exception("TEST"); 
    } 
    catch(Exception ex) 
    { 
     ExceptionDispatchInfo.Capture(ex).Throw(); 
     throw; // So the compiler doesn't complain about methods which don't either return or throw. 
    } 
} 

3.

void CallingMethod() 
{ 
    try 
    { 
     throw new Exception("TEST"); 
    } 
    catch 
    { 
     throw; 
    } 
} 

4.

void CallingMethod() 
{ 
    try 
    { 
     throw new Exception("TEST"); 
    } 
    catch(Exception ex) 
    { 
     throw new Exception("RETHROW", ex); 
    } 
} 

caso 1 y el caso 2 le dará un seguimiento de pila, donde el número de línea de código fuente para el método CallingMethod es el número de línea de la línea throw new Exception("TEST").

Sin embargo, el caso 3 le dará un seguimiento de pila donde el número de línea del código fuente para el método CallingMethod es el número de línea de la llamada throw. Esto significa que si la línea throw new Exception("TEST") está rodeada por otras operaciones, no tiene idea de en qué número de línea se lanzó realmente la excepción.

El caso 4 es similar con el caso 2 porque se conserva el número de línea de la excepción original, pero no es un verdadero revés porque cambia el tipo de la excepción original.