469,317 Members | 1,961 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,317 developers. It's quick & easy.

Question on processes 'n' threads #2

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
Nov 16 '05 #1
9 1193
Beeeeeeeeeeeeves,

See inline:

"Beeeeeeeeeeeeves" <Be**************@discussions.microsoft.com> wrote in
message news:2B**********************************@microsof t.com...
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.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

Thanks

Nov 16 '05 #2
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


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,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
Nov 16 '05 #3

"Beeeeeeeeeeeeves" <Be**************@discussions.microsoft.com> wrote in
message news:02**********************************@microsof t.com...
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
Nov 16 '05 #4
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.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Kiran" <ki****@abc.com> wrote in message
news:OD**************@TK2MSFTNGP11.phx.gbl...

"Beeeeeeeeeeeeves" <Be**************@discussions.microsoft.com> wrote in
message news:02**********************************@microsof t.com...
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

Nov 16 '05 #5
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]
ja******@online.microsoft.com

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

"Kiran" <ki****@abc.com> wrote in message
news:OD**************@TK2MSFTNGP11.phx.gbl...

"Beeeeeeeeeeeeves" <Be**************@discussions.microsoft.com> wrote in
message news:02**********************************@microsof t.com...
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

Nov 16 '05 #6
"Beeeeeeeeeeeeves" <Be**************@discussions.microsoft.com> wrote in
message news:02**********************************@microsof t.com...
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,
--
Tom Tempelaere
Nov 16 '05 #7
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
"TT (Tom Tempelaere)" <_N_0SPA|/\|t*******@hotmail.com|/\|APS0_N_> wrote in
message news:vq**********************@phobos.telenet-ops.be...
"Beeeeeeeeeeeeves" <Be**************@discussions.microsoft.com> wrote in
message news:02**********************************@microsof t.com...
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,
--
Tom Tempelaere

Nov 16 '05 #8
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.

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:uD**************@TK2MSFTNGP10.phx.gbl...
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.


Nov 16 '05 #9

"Beeeeeves" <123455123457895123456789> wrote in message
news:OK**************@tk2msftngp13.phx.gbl...
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.


Nov 16 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Michael Williams | last post: by
8 posts views Thread by AnalogKid | last post: by
3 posts views Thread by Thomas Schmid | last post: by
11 posts views Thread by Markus Breuer | last post: by
reply views Thread by Stephen Barrett | last post: by
2 posts views Thread by Abubakar | last post: by
35 posts views Thread by Carl J. Van Arsdall | last post: by
9 posts views Thread by Carl Johansson | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by harlem98 | last post: by
1 post views Thread by Geralt96 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.