views:

174

answers:

2

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.

alt text

(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.

+1  A: 

Check in the debugger exception settings to see if you're telling the debugger to break when NullReferenceException is thrown.

John Saunders
That still wouldn't explain why it's causing my application to bring up my exception dialog when it's run without the debugger.
chaiguy
The odd thing is, it's showing me the exact line in the debugger with the catch block beneath it with a grey background, but the breakpoint in the catch block is never being hit. I'll post an image...
chaiguy
@chaiguy: I've seen something like that when the current PC was in code _called_ from the grey area, but was not within it. The current PC was not displayable (no source code). I wonder what you'd see if you turned on Disassembly mode?
John Saunders
I'm not sure I'd know what to look for if I did (how might I do that?). Another odd thing is that there's a "NativeToManaged" transition immediately above this point on the call stack, and below the point where the NullRef actually occurs. Strangely there's no "ManagedToNative" transition.
chaiguy
...and to answer your initial question, no the debugger is not set to break on any exceptions being thrown, only not-handled.
chaiguy
A: 

I'm pretty sure you can catch exceptions just fine after an invoke and there's no reflection-specific mechanism required for catching it.

Is the method you're invoking perhaps using threading and throwing the exception in a child thread? This could cause your try-catch to miss the exception if the exception occurs in an anychronous thread that's not finished before you leave the try-catch statement.

Tim Schneider
Hmm, no, no child threads going on here.
chaiguy