"Beeeeeves" <12345512345789 5123456789> wrote in message
news:OK******** ******@tk2msftn gp13.phx.gbl...
I do shut down threads, but using Thread.Abort() followed by
Thread.Join(), but in this program I do catch the ThreadAbortExce ption that is generated.
But in my other program I was just trying to weigh up whether it was worth
putting handlers in the worker thread functions, when there might have
been some rule that states they can't bring down the main app anyway... but it
seems people are divided
I believe it is worth putting handlers in all worker threads. Here's my take
on it...
It's easy to do.
Even though the current CLR implementation does not bring down an app when a
manual thread has an unhandled exception, this may change in future
releases. This is a policy decision that the app itself should make, not the
runtime.
An unhandled exception means that something unexpected went wrong and the
app not only did not do something about it, it did not even notice - this
cannot be a good thing, and is likely to be a very bad thing. It is often
the source of many subtle bugs, and can also be the source of major bugs. It
can result in an app becoming partially hung - the UI may be responsive but
the main thread may be waiting for an operation to complete that never will.
If you are using asynchronous IO in a worker thread (e.g. calling a
webservice), then all methods that call EndInvoke with the AsyncResult
object should be prepared to deal with an exception, because this may
rethrow the original exception that occurred during processing and was
swallowed.
IMO if exceptions are used as intended you should never get one unless
something has gone wrong. This argues that the application should do
something meaningful with it, and this usually indicates that it should at
least write an entry to the event log (or do something similar) to leave
enough breadcrumbs behind for support to help diagnose the problem.
Obviously there are always deviations from this, but I find it to be a
useful guide.
I define an unhandled exception handler to record that one occurred so that
if I get one I know where to start looking in the code - it means that
there's a chunk of code somewhere that needs to have a handler.
Unhandled exceptions in finalizers and dispose methods are especially
troubling and should be treated as major problems. Some cleanup scenarios
are complicated and necessary, and for something to go wrong in one usually
indicates a problem that needs to be addressed. It may also lead to leaks,
and if dealing with unmanaged code/COM, etc. the leaks may extend beyond the
boundaries of the .net runtime.
IMO, I think it was a bad decision to allow unhandled exceptions to not
crash an app. In Win32 an unhandled exception, in any thread, crashed the
app, and I think that was a better way to go.
