Stacktrace in IInterceptionBehavior Implementation

Feb 19, 2011 at 10:31 AM


think of a simple IInterceptionBehavior Implementation in lets say ThrowExceptionBehavior.cs below. Unfortunately the stacktrace shows only the invocation in the main program, but gives us no hint related to our Behavior implementation... Is there a way to retain the stacktrace information from the behavior implementation?

Begin of Stacktrace...

   bei DynamicModule.ns.Wrapped_IMyEntityView_1793d584508b4990a5f3ffa0722800dd.set_Zahl(Int32 value)
   here should be a hint to our behavior implementation but it isnt...
   bei NHTest.Program.Main


public class ThrowExceptionBehavior : IInterceptionBehavior

        public IEnumerable<Type> GetRequiredInterfaces()
            return Type.EmptyTypes;

        public IMethodReturn Invoke(IMethodInvocation input, GetNextInterceptionBehaviorDelegate getNext)
              return input.CreateExceptionMethodReturn(new Exception("Exploding"));

        public bool WillExecute
            { return true; }


Btw. Thanks to all who are working on unity. In bundle with Enterprise Library it gives you a mind blowing set of functionality with a minimum superclean code. AOP is the future. Once you got this concept I can't understand how I ever could hack without it. I am sure this concept will have a huge impact on development practices.



first of all thanks to all

Feb 21, 2011 at 12:02 AM

The problem is that a stack trace is only generated at the point you throw. Since you're not actually throwing in your behavior, you don't get a stack trace until it does get thrown (in the proxy).

The design assumption was: if you want an exception that acts like it came from the target (so that other behaviors in the chain also can intercept and process the exception) then use input.CreateExceptionMethodReturn. If, on the other hand, there's an actual error in your behavior, throw. The other behaviors in the chain will not automatically (unless they include a try-catch block) get to process that exception. But on the other hand, they probably shouldn't be anyway, since it's an error in the behavior.

Hope this helps explain the current behavior.