3

Okay, I know it's dangerous, I know it's deprecated, and I know using it would make baby Jesus cry. I think I'm aware of the implications of calling it and have read this related question.

Here's my scenario. I would like to test a data processing library. It runs multiple jobs, one per thread. Each job only communicates with other jobs via an out-of-process queueing system. Otherwise, jobs are independent: there is no shared state between threads, at least not in my code base.

I would like to test that if some terrible thing such as an OutOfMemoryError or a cosmic ray killing the VM happens at some random point in a job, that the rest of the system is okay. Therefore I want to stop a thread at a completely arbitrary point, and killing the thread should not leave resources accessible by other threads in an undefined state. The job logic is part of a framework that I don't want to compromise for the purposes of this test so it's not viable to intersperse random exits throughout the job code.

Is this an appropriate use of Thread.stop()? And so that this is not an XY question, is there any other practical way to accomplish my goal? (I suppose it could be done with bytecode instrumentation but I think that would be tremendously difficult.)

Reinstate Monica
  • 2,420
  • 14
  • 23
  • 1
    Will `Thread.interrupt` work for you? – tsolakp Dec 07 '17 at 20:55
  • *I want to stop a thread at a completely arbitrary point.* Arbitrary conditions should usually be avoided in unit tests, since they can make results difficult or impossible to reproduce. – shmosel Dec 07 '17 at 20:56
  • @tsolakp Currently I'm using `Thread.interrupt` and jobs gracefully exit on interruption but that only tests correctness exiting at certain points where the job already expects to exit. – Reinstate Monica Dec 07 '17 at 20:56
  • @shmosel It wouldn't be a unit test and I could record the stack trace of exit, along with copious logging. Still, bugs might be hard to reproduce but the test could nonetheless point to errors. – Reinstate Monica Dec 07 '17 at 20:57
  • It's an interesting question, but also its hard to envision that this is a real requirement. If you're all that worried about the state of a thread, I think only a core dump will actually reveal the full state. Exceptions don't show heap memory, and that's going to be part of your state. Personally, I think the requirement is bogus and testing and code reviews should be adequate. If you really need to dig into a JVM's guts, only a full memory dump will do. – markspace Dec 07 '17 at 21:05
  • @markspace "testing and code reviews should be adequate": This is part of testing. Code reviews check for style and basic bugs and in no way substitute for testing. I want this code to be bullet proof but I don't need to dig into the JVM or dump the heap. Unit and integration tests don't do those things and they are still useful. – Reinstate Monica Dec 07 '17 at 21:07
  • If you are using `Thread.interrupt`, can you not poll the interrupted status and throw a new `InterruptedException` without the cleanup at critical points in the thread? Its messy but would create the kind of mayhem you're looking for. – Michael McKay Dec 07 '17 at 21:24
  • @MichaelMcKay I'm trying to test production code and I don't want to compromise/clutter it by littering it with checks. And a failure could occur in a library as well, such as the one I'm using for queueing. So I don't think that's a practical approach in this case. – Reinstate Monica Dec 07 '17 at 21:26
  • Thread.stop() throws a special throwable so it's very similar to interrupt. You could even catch it. If your code isn't written to release resources as it unwinds from an exception, stop won't do anything special for you. You can use stop () to specifically bypass logic catching InterruptedException, I don't see any other legitimate use of stop and even that is here or there – Lev Kuznetsov Dec 08 '17 at 09:39

0 Answers0