uncaught exception handling

[Nicole Lacoste]

Hi,

Kind of a general question. Here's my situation...

I have an application that starts lots of threads that are dependent on each other (producers and consumers). If one of the threads die I want the other threads to know about it. All my threads respond to interrupts and all my threads are subclasses of a class, MyThread, that has a method

void dying(final Throwable e)

which interrupts all the other threads in the same group if the thread dies from a non null throwable. Anywhere in the run of my Threads where I return, I call dying

void dying(e)

with either an exception or null.

The problem is with uncaught exceptions. There seems to be two ways to solve the problem;
1. override the uncaughtException method as

final public void uncaughtException(final Thread t, final Throwable t)
{
   if (t instanceof MyThread)
   {
     ((MyThread)t).dying(e);
   }
}

2. wrap all the code in my runs with a

try 
{
   // run code
}
catch(Throwable e)
{
   dying(e);
}

What are the reasons to choose one over the other?

Thanks,

Nicole

PS one thing I noticed is that for ordinary try-catch-finally blocks the finally is called after the catch, but if I use the uncaughtException handler the order is try-finally-uncaughtException.
[ February 20, 2007: Message edited by: Nicole Lacoste ]

[Mr. C Lamont Gilbert]

I think either works. Are you using threadGroups here?

[Nicole Lacoste]

Hi,


Yes I am using ThreadGroups (sorry if that wasn't clear), and yes both approached work. I was just wondering if there is some reason to prefer using thread groups and uncaught exceptions over try catch in the run. There might be something I just haven't thought of.

Nicole

[Mr. C Lamont Gilbert]

I would prefer method 1 since I think its a bit more clear what you are doing.