Currently error conditions are signaled using a single exception type, JbpmException.
Using problem specific exception subclasses would make it possible for the client code to deal with different error conditions differently .

Example - current GetOutcomes command implementation:

package org.jbpm.pvm.internal.cmd;
...
public class GetOutcomes implements Command<Set<String>> {

...
public Set<String> execute(Environment environment) {
DbSession dbSession = environment.get(DbSession.class);
TaskImpl task = dbSession.get(TaskImpl.class, Long.parseLong(taskId));
if (task==null)

{ throw new JbpmException("task "+taskId+" doesn't exist"); }

...

Introducing problem specific exception subclasses would allow client code to handle errors much better:
public Set<String> execute(Environment environment) {
DbSession dbSession = environment.get(DbSession.class);
TaskImpl task = dbSession.get(TaskImpl.class, Long.parseLong(taskId));
if (task==null)

{ throw new TaskDoesNotExistException("task "+taskId+" doesn't exist"); }

for example if a custom TaskDoesNotExistException (public class TaskDoesNotExistException extends JbpmException) was thrown in GetOutcomes.execute when a task is not found, then the caller code would be able to distinguish this problem from say a transient database connectivity problem. It could display a user friendly error message rather than showing a generic error message etc:

try {
//...
Set<String> outcomes = taskService.getOutcomes()
//...
}
catch(TaskDoesNotExistException e) {
// Show error message: The task you tried to access does not exist
}
catch(JbpmException e) {
// Show error message: Something went wrong in the workflow!!
}

The same approach for process instances, executions, variables, etc. could be used to allow building robust client code.