[concurrency-interest] throwing RuntimeException vs ExceptioninThreadPoolExecutor

Kai Meder stuff at kai.meder.info
Sun May 30 10:59:28 EDT 2010

On 30.05.2010 01:57, David Holmes wrote:
> Re-reading this ...
>> Kai Meder writes:
>>> I'm hacking in Scala and use the ThreadPoolExecutor. I use an Exception
>>> "TerminatedChannel", using the trait ControlThrowable, inside my tasks
>>> in for ControlFlow (please no discussion about this).
>>> When using TerminatedChannel as a RuntimeException it passes the
>>> attached ThreadPoolExector-CodeBlock. If used just as a Throwable the
>>> ThreadPoolExecutor suspends the thread, as TerminatedChannel
>>> broke its neck.
> So Throwable is a checked-exception and it should not be possible (under
> normal circumstances) for your task to throw it as Runnables do not throw
> checked exceptions. You can get around this by using some reflection
> techniques or native code to throw "impossible" exceptions. If you did this
> there may some internal piece of code that encounters a problem that results
> in the behaviour you observe.
If declaring the TerminatedChannel as RuntimeException with
ControlThrowable it is an Unchecked Exception and seems to leave the
ThreadPoolExecutor, caught by the "proper" exception-handler outside the
task. The ThreadPoolExecutor's Task#X-Thread does not get "suspended",
the control flow continues normally.

> That said I don't understand what you mean by "suspends the thread" above.
The ThreadPoolExecutor Task#X-Thread encounters the NON-RuntimeException
and enters the JVM-"Suspended" ThreadState, as indicated by the
Debug-View of eclipse.

More information about the Concurrency-interest mailing list