recovering from an exception

[John Roberts]

Hi,

We are writing a fairly extensive shell replacement using the compact
framework. Each 'applet' is run within the same process using a different
thread (this was done to save memory resources). When an applet throws an
exception that is not caught, the exception does bubble through to the
message pump, DispatchMessage, where I can handle it. I would like to handle
the exception and then quit the applet nicely whilst leaving everything else
running. However, it seems that the compact framework has other ideas as all
other applets, each with its own window and thread, are killed - including
the shell. Does anyone know what mechanism is responsible for doing this and
whether it can be prevented or reversed? I'm guessing that something in the
managed default window proc catches the exception, tries to quit the
application and then re-throws it.

Cheers,
- John

 

[John Roberts]

I've found an answer to my own question. It seems that the compact framework
posts the WM_QUIT message to all windows when an exception escapes unhandled
back to the windows procedure. The solution is to not exit the threads of
applets that are unaffected by the exception in the event of WM_QUIT. It is
possible to do this by modifying the message pump.

I've also noticed that the method Control.Invoke has a bug if the event
handler throws an unhandled exception which in turn triggers the window to
be closed. In this circumstance, the calling thread never returns from
Invoke and the process is left with a 'rogue' thread. I have been able to
work round this problem by implementing my own version of Invoke.