Load Event Handler is swalling an exception

[Greg Robinson]

We have a MdiParent that calls Show on a MdiChild.

Inside the MdiChild Load Event handler, we do a database trip. The db trip
causes a SqlClient.SqlException.

Back in the MdiParent, we catch and handle the exception.

This works when running in Debug mode from the IDE. The exception is caught
and handled per the code wriutten inside the catch block.

This does not work when not running in debug mode from the ide or when
running the exe from a private folder. The exception is never caught by the
MdiParent. The exception bubble up and is caught by our last chance handler
(Application.ThreadException).

What is the differnece in the environments?

 

[Guest]

Hi Greg,

The .NET Framework changes the behaviour of the FPreTranslateMessage method
in the Application class and the AssignHandle method of the NativeWindow
class (and a few other places) depending on whether you have a debugger
attached or not. If you have a debugger attached the caught exception is
rethrown, if you don't it's passed to the default OnThreadException handler.

This behaviour is dependent on a few things - for example having a
Application.ThreadException handler means you shouldn't have the behaviour
you're seeing, your exception should always go to your
Application.ThreadException handler. So it is a little odd that you're seeing
it caught by the try/catch at all.

I think you can override it with a config file or a setting in the registry.
The best way to check this is to turn "Break On Exception" on and type
"System.Windows.Forms.NativeWindow.WndProcShouldBeDebuggable" into the watch
window when your exception occurs. If you have your
Application.ThreadException handler hooked up, it should return false for
you, even when the debugger is attached.

That you sometimes catch the exception in your Mdi Parent's try/catch means
that System.Windows.Forms.NativeWindow.WndProcShouldBeDebuggable is returning
true for you in certain circumstances. Is it possible you're attaching the
Application.ThreadException handler after you've constructed the forms? That
would explain the behaviour you're seeing. You should attach
Application.ThreadException before constructing any controls, preferably on
the first line of your app.

You can test this in your various environments by making a call to
Environment.StackTrace in your exception handlers (the one in the Mdi Parent
and the Application.ThreadException handler) and comparing them. You can
write them to a file and post them here if you like - I'll be happy to have a
look over them.

Hope this helps.

Regards,
Matt Garven