Cómo volver a lanzar la excepción interna de una TargetInvocationException sin perder el seguimiento de la pila

Question

Tengo muchos métodos que están llamando usando Delegate.DynamicInvoke. Algunos de estos métodos hacen llamadas a la base de datos y me gustaría tener la capacidad de atrapar un SqlException y no atrapar el TargetInvocationException y buscar entre sus internos para encontrar lo que realmente salió mal.

yo estaba usando este método para volver a lanzar pero despeja el seguimiento de la pila:

try 
{ 
     return myDelegate.DynamicInvoke(args); 
} 
catch(TargetInvocationException ex) 
{ 
    Func<TargetInvocationException, Exception> getInner = null; 
    getInner = 
     delegate(TargetInvocationException e) 
     { 
     if (e.InnerException is TargetInvocationException) 
      return getInner((TargetInvocationException) e.InnerException); 

     return e.InnerException; 
     }; 

    Exception inner = getInner(ex); 
    inner.PreserveStackTrace(); 
    throw inner; 
} 

PreserveStackTrace El método es un método de extensión hasta me fijo gracias a otro puesto (no sé lo que realmente hace) . Sin embargo, esto no parece conservar la traza ya sea:

public static void PreserveStackTrace(this 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); 
    mgr.DoFixups(); 
} 

Answer 1

Si lo que desea es volver a lanzar una excepción interna que conserva su traza de la pila, puede hacerlo con un método como este:

public static void Rethrow(this Exception ex) 
{ 
    typeof(Exception).GetMethod("PrepForRemoting", 
     BindingFlags.NonPublic | BindingFlags.Instance) 
     .Invoke(ex, new object[0]); 
    throw ex; 
} 

Esta técnica es utilizada por Rx (y se expone por ellos como un método de extensión Exception.PrepareForRethrow) y también es utilizado por el Async CTP por su sistema de desenvolvimiento automático (sin una API expuesta públicamente).

Tenga en cuenta, sin embargo, que esta técnica es técnicamente incompatible. Esperemos que Microsoft agregue una API oficial para esto en el futuro. Una sugerencia has been opened en Microsoft Connect si desea votar por ella.

Actualización: Se ha agregado una API oficial a .NET 4.5: ExceptionDispatchInfo.

Answer 2

IIRC no es posible preservar excepción por completo, sin embargo Seguimiento de la pila se puede conservar con un poco de reflexión. Aquí está la publicación de blog que describe cómo hacerlo: http://iridescence.no/post/Preserving-Stack-Traces-When-Re-Throwing-Inner-Exceptions.aspx

Answer 3

Debe tener en cuenta por qué .NET ajusta la excepción con una TargetInvocationException en lugar de simplemente dejar pasar la excepción original. Hay una muy buena razón para eso, no es obvio de dónde viene la verdadera razón de la excepción. ¿Fue porque la llamada de DynamicInvoke() tiene borked? No es improbable, no hay nada que el compilador pueda hacer para garantizar que se pasen los argumentos correctos. ¿O el método del objetivo invocado se lanzó solo?

Necesita saber ambos para juzgar el motivo real de la excepción. La ocultación intencional de TargetInvocationException le dará un tiempo difícil para diagnosticar el origen del problema si fue realmente un problema con la llamada DynamicInvoke(). Evita hacer esto.