Rocky,
There appears to be a small issue in the MethodCaller.cs file on lines 225-229 of your latest trunk code of the CSLA 3.5.
Right now the code found on those lines is catching any and all exceptions that occur as a result of invoking “methodHandle.DynamicMethod”. Then, once an exception has been caught it attempts to return the InnerException, if one exists, of the exception that’s caught.
In my particular situation, I was wrapping a SqlException in my own custom exception and the above code was stripping off my custom exception and returning only the SqlException.
I was a bit baffled by this behavior so I went back the C# 2005 Business Objects book to investigate why the CallMethodException exists in the first place.
On page 183 of your book it states that:
Remember that MethodCaller.CallMethod uses reflection to invoke the business method. When an exception occurs in the business method, a reflection exception is thrown – with the original business exception nested inside. CallMethod() strips off the reflection exception and provides the original business exception as a parameter during the creation of the CallMethodException object.
This appears to explain why the behavior occurs – it’s by design. Granted the quotation was from the CSLA 2.0 days, but the idea should still hold.
Here’s the problem: A ReflectionException is never thrown. I tried various things including all DataPortal operations: Fetch, Insert, Update, Delete and Execute both with an external DataPortal defined in my configuration and without one and haven’t seen any ReflectionExceptions thrown.
If there is a possibility that a ReflectionException will be thrown and I’m not seeing it, one could easily do an “ex is ReflectionException” check and then grab the inner exception, otherwise the whole exception is rethrown.
If this isn’t a bug and is “by design” could you give a little bit of insight?
Thanks!
Yes, good catch!
This is because reflection is no longer used in 3.5. Instead, a dynamic method technique is used - and so of course there's no intermediate reflection exception anymore... I'm glad you noticed this!
I've fixed it in svn - though I also did some cleanup by moving CallMethodException to Csla.Reflection where it belongs (which could be a breaking change I suppose - but needs to happen).
Copyright (c) Marimer LLC