Question on processes 'n' threads #2

[Guest]

Hi

I have a service which starts extra threads which take a long time, this is so it can respond to events while long processes are running. I was just wondering,

a) if an exception is thrown in a worker thread and it is unhandled, does it bring the whole application down or just the worker thread that suffered it?

b) if an exception is thrown in a function which doesn't have exception handling but the function that called it does, will the exception simply propogate up until it finds a handler, and then consider that handler to be the official handler of that exception?

Thanks

 

[Nicholas Paldino [.NET/C# MVP]]

Beeeeeeeeeeeeves,

See inline:

Hi

I have a service which starts extra threads which take a long time, this

is so it can respond to events while long processes are running. I was just
wondering,

a) if an exception is thrown in a worker thread and it is unhandled, does

it bring the whole application down or just the worker thread that suffered
it?

I believe that the application will shut down, as the exception is
unhandled

b) if an exception is thrown in a function which doesn't have exception

handling but the function that called it does, will the exception simply
propogate up until it finds a handler, and then consider that handler to be
the official handler of that exception?

If there is not an exception handler in the function that the exception
was thrown in, then the exception will bubble up the call stack until it is
handled, or, the application terminates.

Hope this helps.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

is so it can respond to events while long processes are running. I was just does
it bring the whole application down or just the worker thread that suffered
it?

I believe that the application will shut down, as the exception is
unhandled

I believe that only the thread where the exception happen is kill, the
others will continue to run, .

I just found this on an article in MSDN:

Here is a summary of the unhandled exception handler default behaviors that
are executing in this application.
a.. Unhandled exceptions that occur on the application's main thread cause
the application to terminate.
b.. Unhandled exceptions that occur in threads other than the
application's main thread are swallowed by the CLR. This includes manual
threads, thread pool threads, and the CLR's finalizer thread. If your
application is a console application, the CLR outputs exception text to the
console (though your application keeps running). If your application is not
a console application, there is no outward indication when an exception
occurs and your application keeps running.
c.. Unhandled exceptions that occur on a thread that is pumping window
messages via the Windows Forms classes are subject to the Windows Forms
unhandled exception handler. A debug dialog box is produced by default, but
this behavior can be overridden (more on this in a moment).



Cheers,

 

[Kiran]

so, "best not to rely on it", then..?

So how can I handle a situation in which I want to show a error message to
the user when one of my child thread throws a exception?

regards
Kiran

 

[Nicholas Paldino [.NET/C# MVP]]

Kiran,

If this is the case, then you will have to marshal a message to the UI
thread (through a call to Invoke on a control that was created on that UI
thread) which would then cause a message to appear.

 

[Jared Parsons [MSFT]]

That would depend on how you are creating your threads. If you are creating
the thread by hand (i.e. calling Thread.Start()) then the best way is to add
a try/catch block to the start function of the thread. Catch the exception
and log the exception at that point.

Generally it's bad practice to swallow System.Exception but at the point you
will be catching it the CLR is just about to swallow it as well. FxCop will
still complain.

If you are using other asynchronous methods that will create additional
threads, you have to handle those on a case by case basis

--
Jared Parson [MSFT]
(e-mail address removed)

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

 

[TT \(Tom Tempelaere\)]

so, "best not to rely on it", then..?

It has the same effect as returning from the thread. You could for instance
not catch the ThreadInterruptedException exception when you want to shut
down your thread using Thread::Interrupt.

Cheers,

 

[Beeeeeves]

I do shut down threads, but using Thread.Abort() followed by Thread.Join(),
but in this program I do catch the ThreadAbortException 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

 

[Kiran]

Nicholas ,

OK I got around the problem using
"AppDomain.CurrentDomain.UnhandledException" which catches exception from
any thread when its not handled there.

you see any problem with this???

Regards
Kiran.

 

[David Levine]

I do shut down threads, but using Thread.Abort() followed by Thread.Join(),
but in this program I do catch the ThreadAbortException 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.