Jak ponownie zgłosić wyjątek wewnętrzny bez utraty śladu stosu w języku C #?

Wzywam, poprzez refleksję, metodę, która może powodować wyjątek. Jak mogę przekazać wyjątek mojemu rozmówcy bez otaczania go odbiciem opakowania?
Powtarzam wyjątek wewnętrzny, ale to niszczy ślad stosu.
Przykładowy kod:

public void test1()
{
    // Throw an exception for testing purposes
    throw new ArgumentException("test1");
}

void test2()
{
    try
    {
        MethodInfo mi = typeof(Program).GetMethod("test1");
        mi.Invoke(this, null);
    }
    catch (TargetInvocationException tiex)
    {
        // Throw the new exception
        throw tiex.InnerException;
    }
}

W .NET 4.5 jest teraz ExceptionDispatchInfoklasa.

Pozwala to uchwycić wyjątek i ponownie go wyrzucić bez zmiany śledzenia stosu:

try
{
    task.Wait();
}
catch(AggregateException ex)
{
    ExceptionDispatchInfo.Capture(ex.InnerException).Throw();
}

Działa to na każdym wyjątku, nie tylko AggregateException.

Został on wprowadzony dzięki awaitfunkcji języka C #, która rozpakowuje wewnętrzne wyjątki od AggregateExceptioninstancji, aby asynchroniczne funkcje języka bardziej przypominały funkcje języka synchronicznego.

Możliwe jest zachowanie śladu stosu przed ponownym rzuceniem bez odbicia:

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
}

To marnuje wiele cykli w porównaniu do dzwonienia InternalPreserveStackTraceprzez buforowanego delegata, ale ma tę zaletę, że polega tylko na funkcjonalności publicznej. Oto kilka typowych wzorców użycia funkcji zachowywania śledzenia stosu:

// usage (A): cross-thread invoke, messaging, custom task schedulers etc.
catch (Exception e)
{
    PreserveStackTrace (e) ;

    // store exception to be re-thrown later,
    // possibly in a different thread
    operationResult.Exception = e ;
}

// usage (B): after calling MethodInfo.Invoke() and the like
catch (TargetInvocationException tiex)
{
    PreserveStackTrace (tiex.InnerException) ;

    // unwrap TargetInvocationException, so that typed catch clauses 
    // in library/3rd-party code can work correctly;
    // new stack trace is appended to existing one
    throw tiex.InnerException ;
}

Myślę, że najlepszym rozwiązaniem byłoby po prostu umieszczenie tego w bloku catch:

throw;

A później wyodrębnij innerexception.

public static class ExceptionHelper
{
    private static Action<Exception> _preserveInternalException;

    static ExceptionHelper()
    {
        MethodInfo preserveStackTrace = typeof( Exception ).GetMethod( "InternalPreserveStackTrace", BindingFlags.Instance | BindingFlags.NonPublic );
        _preserveInternalException = (Action<Exception>)Delegate.CreateDelegate( typeof( Action<Exception> ), preserveStackTrace );            
    }

    public static void PreserveStackTrace( this Exception ex )
    {
        _preserveInternalException( ex );
    }
}

Wywołaj metodę rozszerzenia wyjątku, zanim ją wyrzucisz, zachowa oryginalny ślad stosu.

Nikt nie wyjaśnił różnicy między ExceptionDispatchInfo.Capture( ex ).Throw()zwykłym throw, więc oto jest.

Całkowitym sposobem na ponowne wyłapanie przechwyconego wyjątku jest użycie ExceptionDispatchInfo.Capture( ex ).Throw()(dostępne tylko w .Net 4.5).

Poniżej znajdują się przypadki niezbędne do przetestowania tego:

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 );
    }
}

Przypadek 1 i przypadek 2 dają ślad stosu, w którym numerem kodu źródłowego dla CallingMethodmetody jest numer throw new Exception( "TEST" )wiersza.

Jednak przypadek 3 da ci ślad stosu, w którym numerem linii kodu źródłowego dla CallingMethodmetody jest numer linii throwwywołania. Oznacza to, że jeśli throw new Exception( "TEST" )linia jest otoczona innymi operacjami, nie masz pojęcia, pod którym numerem linii został zgłoszony wyjątek.

Przypadek 4 jest podobny do przypadku 2, ponieważ zachowany jest numer wiersza oryginalnego wyjątku, ale nie jest to rethrow, ponieważ zmienia typ oryginalnego wyjątku.

Jeszcze więcej refleksji ...

catch (TargetInvocationException tiex)
{
    // Get the _remoteStackTraceString of the Exception class
    FieldInfo remoteStackTraceString = typeof(Exception)
        .GetField("_remoteStackTraceString",
            BindingFlags.Instance | BindingFlags.NonPublic); // MS.Net

    if (remoteStackTraceString == null)
        remoteStackTraceString = typeof(Exception)
        .GetField("remote_stack_trace",
            BindingFlags.Instance | BindingFlags.NonPublic); // Mono

    // Set the InnerException._remoteStackTraceString
    // to the current InnerException.StackTrace
    remoteStackTraceString.SetValue(tiex.InnerException,
        tiex.InnerException.StackTrace + Environment.NewLine);

    // Throw the new exception
    throw tiex.InnerException;
}

Należy pamiętać, że może to nastąpić w dowolnym momencie, ponieważ pola prywatne nie są częścią API. Zobacz dalszą dyskusję na temat Bugzilli Mono .

Po pierwsze: nie trać wyjątku TargetInvocationException - jest to cenna informacja, kiedy będziesz chciał debugować różne rzeczy.
Po drugie: Zawiń TIE jako InnerException we własnym typie wyjątku i umieść właściwość OriginalException, która łączy się z tym, czego potrzebujesz (i zachowaj cały stos połączeń nienaruszony).
Po trzecie: pozwól TIE wygasnąć z twojej metody.

Chłopaki, jesteście fajni .. Niedługo będę nekromantą.

    public void test1()
    {
        // Throw an exception for testing purposes
        throw new ArgumentException("test1");
    }

    void test2()
    {
            MethodInfo mi = typeof(Program).GetMethod("test1");
            ((Action)Delegate.CreateDelegate(typeof(Action), mi))();

    }

Kolejny przykładowy kod, który wykorzystuje serializację / deserializację wyjątków. Nie wymaga faktycznego typu wyjątku, aby można go serializować. Używa także tylko metod publicznych / chronionych.

    static void PreserveStackTrace(Exception e)
    {
        var ctx = new StreamingContext(StreamingContextStates.CrossAppDomain);
        var si = new SerializationInfo(typeof(Exception), new FormatterConverter());
        var ctor = typeof(Exception).GetConstructor(BindingFlags.NonPublic | BindingFlags.Instance, null, new Type[] { typeof(SerializationInfo), typeof(StreamingContext) }, null);

        e.GetObjectData(si, ctx);
        ctor.Invoke(e, new object[] { si, ctx });
    }

Na podstawie odpowiedzi Paula Turnersa opracowałem metodę rozszerzenia

    public static Exception Capture(this Exception ex)
    {
        ExceptionDispatchInfo.Capture(ex).Throw();
        return ex;
    }

return exist nigdy nie osiągnął, ale zaletą jest to, że można używać throw ex.Capture()jako jedną wkładką więc kompilator nie zgłosi not all code paths return a valuebłąd.

    public static object InvokeEx(this MethodInfo method, object obj, object[] parameters)
    {
        {
            return method.Invoke(obj, parameters);
        }
        catch (TargetInvocationException ex) when (ex.InnerException != null)
        {
            throw ex.InnerException.Capture();
        }
    }