The Moth

Read the first two parts here and here.

.NET 2.0 fixes the problem with exceptions being swallowed on background threads (based on the VS2005 Beta 1).

When global exception handling is not present, unhandled exceptions on background threads will result in the app either exiting or JIT debug window appearing (based on the reg entry mentioned previously - on my VS2005 Beta 1 installation, the registry entry has the decimal value of 10 so there are clearly more options added in this area; but sorry, I just don't know more about them).

When global exception handling is present, the same rules as today apply, except we also get to see the JIT debugging window before our catch code runs(!). I guess this is for helping us on our dev machines, since by changing the reg entry to 1 the JIT debugging dialog does not appear (phew :-)

UPDATE: The CF 2.0 story is better with the November CTP compared to the Beta 1 story below.

With the CF 2.0, there is still no support for Application.ThreadException or AppDomain.UnhandledException, but the story gets better with try..catch around the main entry point. Basically the bug has been fixed, so the app will not freeze in the Control.Invoke scenario. To recap, if you try..catch the Appliccation.Run then you have two scenarios with CF 2.0:
1. Exceptions on the GUI thread are caught [just as in CF 1.0]
2. Exceptions in other threads (including the Control.Invoke scenario) are caught, BUT before your catch code runs the built-in dialog still appears!

This is the same behaviour with the full Framework (when we use global exception handling) with one major difference. On the desktop we can change the registry setting to override that behaviour - with the CF there is no way that I know of to suppress the built-in dialog :-( Let's hope this situation changes by release time...