<qhelp> <overview>

This rule finds calls to methods that are dangerous to use. Currently, it checks for calls to `Thread.stop`.

Stopping a thread with `Thread.stop` causes it to receive a `ThreadDeath` exception. That exception propagates up the stack, releasing all monitors that the thread was holding. In some cases the relevant code will be protected by catching the `ThreadDeath` exception and cleaning up, but because the exception can potentially be thrown from so very many locations, it is impractical to catch all such cases. As a result, calling `Thread.stop` is likely to result in corrupt data.

</overview> <recommendation>

The best solution is usually to provide an alternate communication mechanism for the thread that might need to be interrupted early. For example, Oracle gives the following example of using a volatile variable to communicate whether the worker thread should exit:

It is also possible to use `Thread.interrupt` and to catch and handle `InterruptedException` when it occurs. However, it can be difficult to handle an `InterruptedException` everywhere it might occur; for example, the sample code above simply discards the exception rather than actually exiting the thread.

Another strategy is to use message passing, for example via a `BlockingQueue`. In addition to passing the worker thread its ordinary work via such a message queue, the worker can be asked to exit by a particular kind of message being sent on the queue.

</recommendation> <references>

- The CERT Oracle Secure Coding Standard for Java: THI05-J. Do not use Thread.stop() to terminate threads.
- Java SE Documentation: Java Thread Primitive Deprecation.
- Java API: Thread.interrupt, BlockingQueue.
</references> </qhelp>