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 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 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
2. wrap all the code in my runs with a
What are the reasons to choose one over the other?
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 ]
I think either works. Are you using threadGroups here?
Joined: Oct 04, 2006
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.