Interception eats the stacktrace

Nov 26, 2008 at 9:53 PM
I found that exceptions thrown from interecpted methods have their stacktrace only up till the dynamic method.

I'm using VirtualMethodInterceptor for interception. It seems that the excpetions are getting rethrown which is modifing the stacktrace.
Nov 26, 2008 at 11:37 PM
Unfortunately true. PIAB has the same issue. It's impossible to do the right thing (preserve the exception and stack trace, but still allow processing it in the call handlers) without resorting to reflection on private members. We also need to support partial trust and Silverlight, neither of which allow that. So we're kind of stuck.

I'd love to hear suggestions on how to fix this, though.

Nov 27, 2008 at 3:17 AM
why is the exception being cought and rethrown? can you give more details on the current imeplentation?

as far as I understand it the VirtualMethodInterceptor works by overriding the interceped method like this:

override someMethod()
//// code before
// code after

if the base.someMethod throw exception I don't why the stactrace get's lost.
Nov 27, 2008 at 5:49 AM
Because that's not what the overriding method looks like. It looks more like:

override SomeMethod()
    MethodInfo someMethodInfo = GetType().GetMethod("SomeMethod");
    HandlerPipeline pipeline = GetHandlerPipeline(someMethodInfo);

    IMethodReturn result = pipeline.Invoke(delegate (IMethodInvocation methodCall, GetNextDelegate getNext) {
        try {
            return methodCall.CreateMethodReturn(null);
        catch(Exception ex)
             return methodCall.CreateExceptionReturn(ex);

with some variations depending on the type and number of arguments and return values.

The pipeline.Invoke method runs the call through all the configured handlers. In order to give the handlers a shot at the return value, it's packaged up into an IMethodReturn object, which can either contain the return value (or null if there's no return) or any exception that was thrown from the method.