I have a method running in a seperate thread. The thread is created and started from a form in a windows application. If an exception is thrown from inside the thread, wha
Throwing exceptions between threads is not easy and probably not desired. instead you can pass the exception using a shared data structure or variable and use waitHandle to wait on the 1st thread.
Probably a better way would be to pass a delegate into the thread instead of a reference to the form itself.
Use the BackgroundWorker class in the .NET framework instead. It is the best practice for performing UI work on a different thread.
I totally agree with Dror. In a formal way we can call this structure as FaultContract. Fundamentally when an exception has happened in another thread, the client thread can hardly do any thing at that moment except that to collect that information and act accordingly in it's own theread. If the thereads are in different AppPool then there is an extra complexity of Serialization (that can be a seperate topic altogether).
So you're using Invoke to marshall back to the UI thread, by the looks of it - which is exactly what you need to do. I'd personally use an Action<Exception> for simplicity's sake, and possibly BeginInvoke instead of Invoke, but basically you're doing the right thing.