Exceptions Thrown in Background Threads

Trying to catch the SomeException in TryToDoSomethin g doesn't seem to work, presumably because the exception is thrown in a separate thread. Is this
correct?
That is correct. You must catch the exception on which it is thrown.

If so, what's the best was of dealing with this exception so that I can
call ShowErrorMessag e in the main thread when it's thrown?

Here's a way to do that for purposes of illustration; I would not actually
do it this way.

private Exception theException = null;
void MainEntryPointT oTryToDoSomethi ng()
{
Thread thread = new Thread(new ThreadStart(DoS omething);
thread.IsBackgr ound = true;
thread.Start();
thread.Join(); // wait until thread terminates
if ( theException != null )
ShowErrorMessag e(theException) ;
}

void DoSomething()
{
try
{
DoSomethingWhic hMightThrowAnEx ception();
|}
catch(Exception ex)
{
theException = ex; // save it
}
}
Basically the idea is the save the exception object so that it is available
to the thread which will display the error message. This example used a
global variable, theException. A better way to handle this is to use the
Async pattern as used by the BCL
Note also that you must use thread.Join, or some other synchronization
primitive such as an async callback, to correctly rendevous when the thread
is done.

David Levine wrote:

Here's a way to do that for purposes of illustration; I would not actually
do it this way.
I like the simplicity of this solution. Why wouldn't you do it this way --
is it a bad idea?
A better way to handle this is to use the
Async pattern as used by the BCL

Hmm... I've never heard of this. Google didn't turn up anything, either.

Thanks for the help.

Cool Guy wrote:

Consider:

[begin code]

void Start()
{
if (!TryToDoSometh ing())
ShowErrorMessag e();
}

void TryToDoSomethin g()
{
try
{
Thread thread = new Thread(new ThreadStart(DoS omething);
thread.IsBackgr ound = true;
thread.Start();

return true;
}
catch (SomeException)
{
return false;
}
}

void DoSomething()
{
DoSomethingWhic hMightThrowASom eException();
}

[end code]

Trying to catch the SomeException in TryToDoSomethin g doesn't seem to
work, presumably because the exception is thrown in a separate
thread. Is this correct?
Yes.
If so, what's the best was of dealing with this exception so that I
can call ShowErrorMessag e in the main thread when it's thrown?

Use events. Assume you have a class "Main", which controls your
application's main thread (e.g. a Windows Form), and a class "Worker" that
performs lengthy operations on a separate thread to avoid blocking Main's
thread. If Worker exposes an event "Error", which is triggered whenever an
exception needs to be communicated to Worker's owner, Main can simply
subscribe to the Error event through standard event handling:

/* Note that ErrorEventArgs and ErrorEventHandl er do already exist in
System.IO */

class Main {
private Worker worker;

public Main() {
this.worker = new Worker();
this.worker.Err or += new ErrorEventHandl er(this.Worker_ Error);
}

private void Worker_Error(ob ject sender, ErrorEventArgs e) {
// CAVEAT: If this is a WinForm class, first marshal the call
// back to the UI thread!
// Do something... display message, log to file, etc.
}
}

class Worker {
public event ErrorEventHandl er Error;

public void Work() {
// kick off DoWork() in another thread
}

protected virtual void OnError(ErrorEv entArgs e) {
ErrorEventHandl er handler = Error;
if (handler != null) {
handler(this, e);
}
}

private void DoWork() {
try {
// heavy stuff...
}
catch (Exception ex) {
OnError(new ErrorEventArgs( ex));
}
}
}

Of course this approach allows to to communicate anything back to Main,
including completion results of Work(). Plus, it nicely abstracts from how
Work() actually makes DoWork() run on another thread... whether it uses its
own managed thread, an async delegate, whatever -- the approach is the same.

Note the CAVEAT comment in Worker_Error: If you use this approach in Windows
Forms apps, you *must* protect all such callbacks by assuring each call is
marshalled back to the UI thread if necessary, using Control.InvokeR equired
and Control.Invoke( ).

Cheers,

--
Joerg Jooss
jo*********@gmx .net

"Cool Guy" <co*****@abc.xy z> wrote in message
news:9g******** *******@cool.gu y.abc.xyz...

David Levine wrote:

Here's a way to do that for purposes of illustration; I would not
actually
do it this way.

I like the simplicity of this solution. Why wouldn't you do it this
way --
is it a bad idea?

A better way to handle this is to use the
Async pattern as used by the BCL

Hmm... I've never heard of this. Google didn't turn up anything, either.

Here is a sample running a thread proc on a threapool thread using async
delegates. Check msdn for details.

using System;
using System.Threadin g;
// Async delegate
public delegate void Proc(StateObjec t o);

public class Forked {
static void Worker(StateObj ect o) {
Console.WriteLi ne("Thread {0}, executing Worker, " + "is {1}from the
thread pool.",Thread.C urrentThread.Ge tHashCode(),
Thread.CurrentT hread.IsThreadP oolThread ? "" : "not ");
int r;
int y = 0;
r = 10/y; // Do something really nasty
}

public static void Main() {
Proc proc = new Proc(Worker);
// Do some work using an async. delegate (running on a threadpool thread)
IAsyncResult call = proc.BeginInvok e(null, null, null);
// Do some other work .....
Console.WriteLi ne("Primary thread {0}",
Thread.CurrentT hread.GetHashCo de());
try {
//Asynch. Rendez-vous. Just call EndInvoke at some point within a try
block and you'll see the exception.
proc.EndInvoke( call);
}
catch (Exception ex) {
Console.WriteLi ne("{0}", ex.Message);
}
}
}
Willy.

On second thoughts, this wouldn't work in my situation, because I need to
leave MainEntryPointT oTryToDoSomethi ng after the call to Thread.Start if an
exception isn't thrown.

At current, MainEntryPointT oTryToDoSomethi ng waits until the thread is
finished even if an exception isn't thrown.

I guess I'll have to use events like Joerg suggested. Or is this possible
with some other method?

Hi Cool Guy,

You can set up a global exception handler, similar to this:

using System;
using System.Threadin g;

public class Test
{
public void GlobalException Handler(object sender,
UnhandledExcept ionEventArgs e)
{
Console.WriteLi ne(e.ExceptionO bject.ToString( ));
}

public static void Main()
{
Test t = new Test();
AppDomain.Curre ntDomain.Unhand ledException += new
UnhandledExcept ionEventHandler (t.GlobalExcept ionHandler);
t.Start();
}
void Start()
{
if (!TryToDoSometh ing())
Console.WriteLi ne("!TryToDoSom ething()");
}

bool TryToDoSomethin g()
{
try
{
Thread thread = new Thread(new ThreadStart(DoS omething));
thread.IsBackgr ound = true;
thread.Start();

thread.Join();

return true;
}
catch (ApplicationExc eption)
{
return false;
}
}

void DoSomething()
{
throw new ApplicationExce ption("Test Exception");
}
}

Joe
--
Joe Mayo, Author/Instructor
Need C#/.NET training?
visit www.mayosoftware.com
C# Tutorial - www.csharp-station.com

"Cool Guy" <co*****@abc.xy z> wrote in message
news:56******** *******@cool.gu y.abc.xyz...

Consider:

[begin code]

void Start()
{
if (!TryToDoSometh ing())
ShowErrorMessag e();
}

void TryToDoSomethin g()
{
try
{
Thread thread = new Thread(new ThreadStart(DoS omething);
thread.IsBackgr ound = true;
thread.Start();

return true;
}
catch (SomeException)
{
return false;
}
}

void DoSomething()
{
DoSomethingWhic hMightThrowASom eException();
}

[end code]

Trying to catch the SomeException in TryToDoSomethin g doesn't seem to work, presumably because the exception is thrown in a separate thread. Is this
correct?

If so, what's the best was of dealing with this exception so that I can
call ShowErrorMessag e in the main thread when it's thrown?

I would recommend not doing it this way. All the other mechanisms provide
the opportunity to respond to the exception when it occurs; or if the
handler is deferred, then another opportunity to handle it occurs when
EndInvoke is called. Also, the timing between catch handlers and finally
blocks are run is well defined.

One problem with using the unhandled exception handler is that the
notification occurs after the ability to respond to the exception has past.
If the exception were to occur on the main thread or a thread that
originated in unmanaged code, then in the 1.1 runtime the application will
terminate immediately after the unhandled event it delivered. In future
versions of the runtime the app may terminate even if the exception occurred
on a worker thread (it may even be a configurable policy decision of the
app). Regardless, I would not rely on this working consistently across
multiple versions of the runtime.

More subtle issues may arise when there are timing constraints between when
an exception occurs, when it is handled, and when finally blocks are run.
Handling an exception from an unhandled exception handler adds to the number
of code paths and changes the timing of when the event is delivered and when
finally blocks are run. This may not be a problem, but then again...
"Joe Mayo [C# MVP]" <jm***@nospamAt CSharpDashStati on.com> wrote in message
news:eH******** ******@TK2MSFTN GP09.phx.gbl...

Hi Cool Guy,

You can set up a global exception handler, similar to this:

using System;
using System.Threadin g;

public class Test
{
public void GlobalException Handler(object sender,
UnhandledExcept ionEventArgs e)
{
Console.WriteLi ne(e.ExceptionO bject.ToString( ));
}

public static void Main()
{
Test t = new Test();
AppDomain.Curre ntDomain.Unhand ledException += new
UnhandledExcept ionEventHandler (t.GlobalExcept ionHandler);
t.Start();
}
void Start()
{
if (!TryToDoSometh ing())
Console.WriteLi ne("!TryToDoSom ething()");
}

bool TryToDoSomethin g()
{
try
{
Thread thread = new Thread(new ThreadStart(DoS omething));
thread.IsBackgr ound = true;
thread.Start();

thread.Join();

return true;
}
catch (ApplicationExc eption)
{
return false;
}
}

void DoSomething()
{
throw new ApplicationExce ption("Test Exception");
}
}

Joe
--
Joe Mayo, Author/Instructor
Need C#/.NET training?
visit www.mayosoftware.com
C# Tutorial - www.csharp-station.com

"Cool Guy" <co*****@abc.xy z> wrote in message
news:56******** *******@cool.gu y.abc.xyz...

Consider:

[begin code]

void Start()
{
if (!TryToDoSometh ing())
ShowErrorMessag e();
}

void TryToDoSomethin g()
{
try
{
Thread thread = new Thread(new ThreadStart(DoS omething);
thread.IsBackgr ound = true;
thread.Start();

return true;
}
catch (SomeException)
{
return false;
}
}

void DoSomething()
{
DoSomethingWhic hMightThrowASom eException();
}

[end code]

Trying to catch the SomeException in TryToDoSomethin g doesn't seem to

work,

presumably because the exception is thrown in a separate thread. Is this correct?

If so, what's the best was of dealing with this exception so that I can
call ShowErrorMessag e in the main thread when it's thrown?

Thanks, that's exactly what I had in mind.

"Willy Denoyette [MVP]" <wi************ *@pandora.be> wrote in message
news:%2******** *******@TK2MSFT NGP12.phx.gbl.. .

"Cool Guy" <co*****@abc.xy z> wrote in message
news:9g******** *******@cool.gu y.abc.xyz...

David Levine wrote:

Here's a way to do that for purposes of illustration; I would not
actually
do it this way.
I like the simplicity of this solution. Why wouldn't you do it this
way --
is it a bad idea?

A better way to handle this is to use the
Async pattern as used by the BCL

Hmm... I've never heard of this. Google didn't turn up anything, either.

Here is a sample running a thread proc on a threapool thread using async
delegates. Check msdn for details.

using System;
using System.Threadin g;
// Async delegate
public delegate void Proc(StateObjec t o);

public class Forked {
static void Worker(StateObj ect o) {
Console.WriteLi ne("Thread {0}, executing Worker, " + "is {1}from the
thread pool.",Thread.C urrentThread.Ge tHashCode(),
Thread.CurrentT hread.IsThreadP oolThread ? "" : "not ");
int r;
int y = 0;
r = 10/y; // Do something really nasty
}

public static void Main() {
Proc proc = new Proc(Worker);
// Do some work using an async. delegate (running on a threadpool

thread) IAsyncResult call = proc.BeginInvok e(null, null, null);
// Do some other work .....
Console.WriteLi ne("Primary thread {0}",
Thread.CurrentT hread.GetHashCo de());
try {
//Asynch. Rendez-vous. Just call EndInvoke at some point within a try
block and you'll see the exception.
proc.EndInvoke( call);
}
catch (Exception ex) {
Console.WriteLi ne("{0}", ex.Message);
}
}
}
Willy.

"David Levine" <no************ ****@wi.rr.com> wrote in message
news:uV******** ******@TK2MSFTN GP15.phx.gbl...

I would recommend not doing it this way. All the other mechanisms provide
the opportunity to respond to the exception when it occurs; or if the
handler is deferred, then another opportunity to handle it occurs when
EndInvoke is called. Also, the timing between catch handlers and finally
blocks are run is well defined.
It appears that an asynchronous delegate was an acceptable solution for OP,
but this isn't always the case. There are times when people need to use a
normal thread, rather than an asynchronous delegate. A specific exception
may be handled on the thread where code can be wrapped in a try/catch block.
However, it isn't practical to write catch blocks for every possible
exception that can be raised. The global exeption handler can serve as a
backup mechanism to keep your program from crashing because of unhandled
exceptions. The decision on whether to catch System.Exceptio n may or may
not have anything to do with timing between catch and finally blocks,
depending on the application.
One problem with using the unhandled exception handler is that the
notification occurs after the ability to respond to the exception has past.

I think it depends on the application as to whether this matters or not.
If the exception were to occur on the main thread or a thread that
originated in unmanaged code, then in the 1.1 runtime the application will
terminate immediately after the unhandled event it delivered.
Sure, global exeption handlers are for managed code. The fact that some
unmanaged code might crash the CLR still doesn't convince me that I
shouldn't use a global exception handler.
In future
versions of the runtime the app may terminate even if the exception occurred on a worker thread (it may even be a configurable policy decision of the
app). Regardless, I would not rely on this working consistently across
multiple versions of the runtime.
Why would you not rely on this working consistently across multiple versions
of the runtime? Microsoft explains how this is done through their
architectural guidance document "Exception Management in .NET":

http://msdn.microsoft.com/library/de...ceptdotnet.asp

I'm open minded enough to hear new ideas and if you have information that
would change my mind, then I'm interested in hearing it.
More subtle issues may arise when there are timing constraints between when an exception occurs, when it is handled, and when finally blocks are run.
Handling an exception from an unhandled exception handler adds to the number of code paths and changes the timing of when the event is delivered and when finally blocks are run. This may not be a problem, but then again...
Right. It could be a problem, i.e. in cases where you caught a specific
exception and want capture some information before disposing a resource.
However, I don't see that as a reason not to have a global exception
handler.


"Joe Mayo [C# MVP]" <jm***@nospamAt CSharpDashStati on.com> wrote in message
news:eH******** ******@TK2MSFTN GP09.phx.gbl...

Hi Cool Guy,

You can set up a global exception handler, similar to this:

using System;
using System.Threadin g;

public class Test
{
public void GlobalException Handler(object sender,
UnhandledExcept ionEventArgs e)
{
Console.WriteLi ne(e.ExceptionO bject.ToString( ));
}

public static void Main()
{
Test t = new Test();
AppDomain.Curre ntDomain.Unhand ledException += new
UnhandledExcept ionEventHandler (t.GlobalExcept ionHandler);
t.Start();
}
void Start()
{
if (!TryToDoSometh ing())
Console.WriteLi ne("!TryToDoSom ething()");
}

bool TryToDoSomethin g()
{
try
{
Thread thread = new Thread(new ThreadStart(DoS omething));
thread.IsBackgr ound = true;
thread.Start();

thread.Join();

return true;
}
catch (ApplicationExc eption)
{
return false;
}
}

void DoSomething()
{
throw new ApplicationExce ption("Test Exception");
}
}

Joe
--
Joe Mayo, Author/Instructor
Need C#/.NET training?
visit www.mayosoftware.com
C# Tutorial - www.csharp-station.com

"Cool Guy" <co*****@abc.xy z> wrote in message
news:56******** *******@cool.gu y.abc.xyz...

Consider:

[begin code]

void Start()
{
if (!TryToDoSometh ing())
ShowErrorMessag e();
}

void TryToDoSomethin g()
{
try
{
Thread thread = new Thread(new ThreadStart(DoS omething);
thread.IsBackgr ound = true;
thread.Start();

return true;
}
catch (SomeException)
{
return false;
}
}

void DoSomething()
{
DoSomethingWhic hMightThrowASom eException();
}

[end code]

Trying to catch the SomeException in TryToDoSomethin g doesn't seem to

work,

presumably because the exception is thrown in a separate thread. Is this correct?

If so, what's the best was of dealing with this exception so that I can call ShowErrorMessag e in the main thread when it's thrown?