Page History

Long-running tasks should provide a mechanism to notify for notifying the application upon abnormal termination. Failure to do so does not cause any resource leaks because the threads in the pool are still recycled, however, but it makes failure diagnosis extremely difficult.

The best way to handle exceptions at the application level is to use an exception handler. The handler can perform diagnostic actions, clean-up and shutdown the Java Virtual Machine ( JVM) , or simply log the details of the failure.

Noncompliant Code Example (Abnormal

...

Task Termination)

This noncompliant code example consists of the PoolService class that encapsulates a thread pool and a runnable Task class. The Task.run() method can throw runtime exceptions such as NullPointerException.

...

The task does not notify the application when it terminates unexpectedly as a result of the runtime exception. Moreover, it does not use any recovery mechanism. Consequently, if Task throws a NullPointerException the exception is ignored.

Compliant Solution (ThreadPoolExecutor

...

Hooks)

Task-specific recovery or clean-up actions can be performed by overriding the {{afterExecute()}} hook of classthe {{java.util.concurrent.ThreadPoolExecutor}} class.  This hook is called when a task concludes successfully concludes by executing all statements in its {{run()}} method, or halts because of an exception. ({{java.lang.Error}} might not be captured on specific implementations,. seeSee [Bug ID 6450211|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6450211] for more information \[[SDN 082008|AA. Java References#SDN 08]\]).  When using this approach, substitute the executor service with a custom {{ThreadPoolExecutor}} that overrides the {{afterExecute()}} hook as shown below:

...

The terminated() hook is called after all the tasks have finished executing , and the Executor has terminated cleanly. This hook can be overridden to release resources acquired by the thread pool, much like a finally block.

...

This compliant solution sets an uncaught exception handler on behalf of the thread pool. An A ThreadFactory argument of type ThreadFactory is passed to the thread pool during construction. The factory is responsible for creating new threads and setting the uncaught exception handler on their behalf. The Task class is unchanged from the noncompliant code example.

...

The {{ExecutorService.submit()}} method can be used to submit a task to a thread pool instead of the {{execute()}} method to obtain a {{Future}} object.  Note that the uncaught exception handler is not called if {{ExecutorService.submit()}} is invoked. This is because the thrown exception is considered to be part of the return status and is consequently wrapped in an {{ExecutionException}} and re-thrown by {{Future.get()}} \[[Goetz 062006|AA. Java References#Goetz 06]\].

...

Furthermore, any exception that prevents doSomething() from obtaining the Future value can be handled as required.

Exceptions

CON32TPS03-EX1: This guideline may be violated if the code for all runnable and callable tasks has been audited to ensure that no exceptional conditions are possible. Nonetheless, it is usually a good practice to install a task-specific or global exception handler to initiate recovery or log the exceptional condition.

...

Failing to provide a mechanism to report for reporting that tasks in a thread pool failed as a result of an exceptional condition , can make it harder to find the source of the issue.

To-Do List

...

||Completed||Priority||Locked||CreatedDate||CompletedDate||Assignee||Name||

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

\[[API 062006|AA. Java References#API 06]\] interfaces {{ExecutorService}}, {{ThreadFactory}} and class {{Thread}}
\[[Goetz 062006|AA. Java References#Goetz 06]\] Chapter 7.3: Handling abnormal thread termination

...