Exception practices when creating a SynchronizationContext?

Question

I'm creating an STA version of the SynchronizationContext for use in Windows Workflow 4.0. I'm wondering what to do about exceptions when Post-ing callbacks.

The SynchronizationContext can be used to Send (execute synchronously) or Post (execute asynchronously) delegates of type SendOrPostCallback. Although in both cases I invoke the delegate on a STA thread, its easy to know how to handle exceptions when executing synchronously. I block the calling thread, Invoke the callback on my worker thread, record any exceptions, unblock the calling thread, and throw any recorded exceptions on the calling thread.

What I should do on the asynchronous Post is less clear. There is no mechanism for transferring that exception from the executing thread back to the calling thread; Post is 100% fire and forget. There is no EndInvoke() or WaitHandle in the SendOrPostCallback. Any exceptions thrown will result in the application being torn down.

Do I have no choice but to let an exception thrown in a Post tear down my application? That seems to be the default behavior in the SynchronizationContexts in the framework (thank you, Reflector). I can't seem to figure out why this is. Shouldn't there be some way to prevent asynchronous Posts from going boom?

Answer 1

In situations like this I let the substitution principle guide me. I would implement the same behavior as the existing instances of SynchronizationContext. To do otherwise violates the substitution principle and could come back to bite you in unexpected ways.

Answer 2

Dying is awesome.

http://stackoverflow.com/questions/576532/is-dying-is-awesome-preferred