Matt, thank you for your quick response.
I do understand the difference now, but when no debugger
is attached, I expect a "normal" behaviour.
According to the documentation (.NET Framework developers
guide, Exceptions Overview c#), the runtime should search
the stack for a caller who handles the exception. When no
match is found, the exception is treated as unhandled.
So when an exceptions occurs somewhere, it bubbles up
until a catch is found which is able to handle the
exception. In my example the first catch found should be
in the button1_Click method. So I expect my messagebox is
displayed in this case.
Instead of displaying my messagebox, the run-time handles
it as an unhandled exception. But it is handled, it is
within a try - catch block !!!
Is this "as designed", a bug or do I miss something ???
Jos
>-----Original Message-----
>Hi Jos,
[quoted text clipped - 74 lines]
>>
>.
Bruce Wood - 11 Feb 2005 17:22 GMT
I think that Matt is describing an effect that I have also seen when
invoking just-in-time debugging: an exception occurs in an event
handler, but the JIT debugger can't tell me where: all it can tell me
is that it happened somewhere inside a .ShowDialog() invocation. So,
I'm left sitting with the debugger pointing to the .ShowDialog() call,
and showing an exception that obviously happened in some event handler
deep inside the form I called.
As Matt said, this has to do with how .NET is handling calls to the
native windowing API. Somehow it plays some trickery with the stack at
run time so that your event handler kinda-isn't-on-the-stack when the
exception occurs, or is in a different thread or something. I'm a bit
foggy on it myself.
Matt Garven - 12 Feb 2005 04:55 GMT
It is as designed, but it's nothing particularly magical - it's just a bit
obscure.
Your try/catch sits lower than the try/catch in the Callback method of
NativeWindow, so it is the Callback method which handles the exception first.
It passes the exception directly to the OnThreadException handler and then
you see the "unhandled exception" dialog.
However, when your debugger is attached (regardless of release mode or debug
mode), NativeWindow uses the DebuggableCallback method instead of the
Callback method. This does not have the try/catch block so the exception is
free to bubble up the stack and therefore gets caught by your try/catch block.
Why? You'll notice that when the debugger is attached the form closes after
the exception occurs (ie it dies horribly). However, when the debugger isn't
attached, the form stays on the screen (ie doesn't die). Perhaps this was
intended as a way to add extra stability to WinForms apps so they don't fall
over every time an exception occurs.
Hope this helps.
Regards,
Matt Garven
> Matt, thank you for your quick response.
>
[quoted text clipped - 122 lines]
> >>
> >.