Re: Handling the throwable "ThreadDeath"

RVic wrote:


     Aside from the JBoss context (of which I'm ignorant), ThreadDeath
is a "normal" occurrence when a thread is terminated by stop(). You
catch it only if you need to do some cleanup before the thread truly
dies, but if there's no cleanup to do you can just let it propagate
outwards. There's really no problem with ThreadDeath.

     ... but there *is* a problem with stop(), and you'll note that
both forms of stop() are deprecated as inherently unsafe. From the
stack trace, it looks like stop() is part of JBoss' way of managing
threads, which seems a Bad Idea (although there might be mitigating
circumstances). Have a look around, and see whether JBoss provides
alternative flavors of thread pool you could use, instead of the kind
that seems to rely on the "unsafe at any speed" stop() method.

     By the way, if you catch ThreadDeath you must re-throw it when
you're through cleaning up. The obvious

    try {
        // thread stuff
    } catch (ThreadDeath td) {
        // clean up
        throw td;
    }

.... looks risky, because if the "clean up" throws something else the
ThreadDeath won't be re-thrown. On the assumption that it's more
important to "preserve" the ThreadDeath event than whatever else
happened, I'd suggest something like

    try {
        // thread stuff
    } catch (ThreadDeath td) {
        try {
            // clean up
        }
        finally {
            throw td;
        }
    }

     But the "real" cure is to stop using stop().

--
Eric.Sosman@sun.com