5

I created a following Class named as ThreadClass (which is a thread as you can see),its structure is something like the following

class SomeTask implements Runnable
{
    boolean someCondition=true;
    public void run() {
        try
        {
            while(someCondition)
            {
            //Here goes the Process Code
            }
        }
        catch(Exception errorException)
        {
            //Catching the Exception
        }
        finally
        {
            ////I expect that this finally should run every time ,whatever happens in the world
        }
    }

}

My question is about the finally block and the stop() method

As above class is implementing Runnable, so I can create the object of this class and start a thread of it by calling start() method.I am also aware of the fact that I can stop this thread by using stop() (Yes , I know it is deprecated) method .

What I want to clarify myself is that, if somehow I need to call the stop method on the ThreadClass's object, then can I rely on the finally block to execute even if the thread is stopped by calling stop() as I am doing some important closing things in the finally block.

Nathan Hughes
  • 94,330
  • 19
  • 181
  • 276
nobalG
  • 4,544
  • 3
  • 34
  • 72
  • 2
    @nobalG I think you are partially asking the wrong question. There should be no "if I need to call a deprecated method". Design your application in a way that does not need deprecated methods. Then you don't have to think what might happen if you are calling them. – GhostCat Mar 31 '15 at 06:36
  • Wouldn't it be better to implement a `myStop()` method, that sets your condition to `false`, so the `while` loop actually stops? Even if you need to run it again later from the point you stopped, you can save your variables/states and continue from that on – Loki Mar 31 '15 at 06:37
  • @EddyG I know i can do that, I was just asking in this particular case – nobalG Mar 31 '15 at 06:38
  • 2
    Voting to re-open. The other question asks about t.interrupt(), not t.stop(). – Solomon Slow Mar 31 '15 at 13:24
  • 3
    If somehow you _need_ to call `t.stop()` then your program is badly designed. If you stop a thread that is doing something, then whatever it was doing will be left unfinished. Unless you are very careful (and every programmer who works on the code besides yourself takes equal care), stopping a thread could leave your program in an invalid state. It is much smarter to use `t.interrupt()` as it was intended, to _ask_ the thread to stop itself and, to clean up after itself before it finally exits. – Solomon Slow Mar 31 '15 at 13:29
  • How about `kill -9`? – biziclop Mar 31 '15 at 16:03

1 Answers1

3

Thread#stop works by throwing a ThreadDeath exception, it doesn't obliterate the thread instantaneously the way System.exit blows away the JVM. ThreadDeath can even be caught, although that's not a good idea. So try blocks are still relevant.

However, complicating this is that if the thread has stop called on it multiple times then, if the second stop is called when the thread is in a finally block then it could be thrown from the finally block so that the finally block would not complete then. And if the thread's cleanup takes a while then it might be likely that stop could be called more than once on it.

Or even if you only call stop once, if at the time that stop is called the thread happens to be already executing its finally block, then the stop would interfere with completing the finally block.

This is similar to what the technotes on Thread primitive deprecation point out:

1) A thread can throw a ThreadDeath exception almost anywhere. All synchronized methods and blocks would have to be studied in great detail, with this in mind.

2) A thread can throw a second ThreadDeath exception while cleaning up from the first (in the catch or finally clause). Cleanup would have to repeated till it succeeded. The code to ensure this would be quite complex.

So there are some cases that are problematic, it would be very difficult to make sure cleanup gets done properly. James' comment is correct, if at all possible you should use interruption for this kind of thing so that the thread can reliably finish its business.

Nathan Hughes
  • 94,330
  • 19
  • 181
  • 276