Command classes returning null should fail more gracefully

Description of problem:
When creating custom Command classes for the AsyncWorkItemHandler, there is an implicit requirement to return at least a new ExecutionResults() instance. This may be documented but returning null causes a strange issue. The process instance will remain active with the RequestInfo object in Error state. The ErrorInfo table will list a null pointer exception in AvailableJobsExecutor but the rest of the trace is in the container and reflective libraries so is unhelpful.

This happened with embedded jBPM.

Version-Release number of selected component (if applicable):
6.2.0 Maven dependencies, I believe this maps to earlier versions.

How reproducible:
Simple, easy

Steps to Reproduce:
1. Setup a simple jBPM app with the services API.
2. Register the AsyncWorkItemHandler in a WID.
3. Create a process using the async task node and pass a command class.
4. Create the command class and make it return null in the execute() method.

Actual results:
jBPM logs an ambiguous record in the ErrorInfo table, the Command class is invoked up to the retry limit, no exception is thrown or logged, process instances remain active, the RequestInfo table shows the request in Error state

Expected results:
An exception is thrown (or at least logged at ERROR level) immediately to notify the user of an invalid method return value or the null return value is handled.

Additional info: