At the moment ActivitiException is used to signal almost all error scenarios.
For example an ActivitiException is thrown if
org.activiti.engine.RuntimeService.startProcessInstanceByKey(String, Map<String, Object>) is called, but the process definition is not found or if org.activiti.engine.TaskService.complete(String, Map<String, Object>) is called, but the task is not found etc.
This behavior makes it hard to handle common error scenarios, e.g. if the task has been completed already and I want to provide user-friendly error handling in my application for task completion, I have two options when using the API, where both of them have issues:
*Always query the task before trying to complete it; if the task is not found, display a human-friendly error message to the user otherwise complete the task. (This puts additional load on the system and is still not fully safe, another instance of the application can complete a task concurrently)
*Try to complete the task, catch ActivitiException and examine the error message; display a human-friendly error message to the user if the message contains "Cannot find task with id " string. (This is a quite obviously wrong and very fragile solution)
I suggest that you add sub-types of ActivitiException to signal common error conditions: e.g. throw a TaskNotFoundException if a task is not found, throw ProcessDefinitionNotFoundException if a process definition is not found and so on.
By making TaskNotFoundException, ProcessDefinitionNotFoundException a sub type of ActivitiException (TaskNotFoundException extends ActivitiException, etc), this would be a fully backwards-compatible change (user code relying on catching ActivitiException would still work)