问题
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?
回答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.
回答2:
Dying is awesome.
Is "Dying is Awesome" preferred?
来源：https://stackoverflow.com/questions/1701482/exception-practices-when-creating-a-synchronizationcontext