Followup: http://stackoverflow.com/questions/3057822/the-uncatchable-exception-pt-2
I'm writing a custom binding engine; my converter is being called before DataContext is set on the target element. This in and of itself isn't a big deal because it will get updated when DataContext eventually receives a value. What is causing problems is the NullReferenceException I'm getting because of DataContext being null, that doesn't seem to want to be caught.
Even though I'm attempting to catch the exception in my value converter:
try {
return ( (MethodInfo)_member ).Invoke( parameter, null );
} catch {
return null;
}
For some reason the debugger is still halting at this point.
(This is backed-up the stack trace a bit to where the catch block is--the actual exception happens inside the _member method. The odd part is the catch block is greyed out yet the breakpoint is never reached.)
Now I'm thinking it could be because the exception is happening in another assembly from where it is being caught (I'm trying to package this in a reusable class library, and _member above points to a method in the application assembly).
If I run my little test app without the debugger it works fine, however my application is a little more robust and has general exception handling which is getting triggered because of this.
I'm wondering if there is just some attribute or something (or perhaps some reflection parameter I'm missing?) I can use to make the exception be caught like it's supposed to.
Update: I'm pretty sure this must be due to the reflection and use of MethodInfo.Invoke. It seems that the exception is first of "TargetInvocationException" with an inner exception of NullReferenceException. It seems the invocation exception is somehow occuring outside of the callstack and therefore isn't being caught inside it. I'm not doing anything with threads, but perhaps there is some kind of implicit thread-shifting going on inside MethodInfo.Invoke?
Does anyone have any ideas how I could force this to be caught, or perhaps another way to invoke a method from a method name that won't have this problem? I'm kind of stumped.