The generated root state machine of Designer service comes with an integrated error handling.

Executable processes work with the concept of transactions. Transactions are equivalent to units of work, that are committed at the end of the session. In case an error occurs during a transaction, the following happens:

1. The error is caught.
   When an exception occurs and is not explicitly caught in the execution diagram by the modeler, the current implementation (and persistent state transaction) skips to its end. All subsequent code is skipped. Then, the error is caught by the persistent state engine.
2. The error handler is invoked.
   The error handler sends an error signal (handleErrorSignal) to the root state machine.
3. The process switches into the error state at transaction end.
   The persistent state engine commits the transaction - and also the error signal. The process switches to the next process step but then goes to the error state.

The process instance is displayed as erroneous. You can now

• Rectify the error and send a retry signal
  You can now look into the error and apply fixes if necessary. The last process step the process has reached is marked by a history state, so it is possible to trigger a retry from this very step. You can either trigger a manual retry, or the process could have auto retry enabled and automatically performs retries in given intervals.

• Abort the process instance
  

  Alternatively, you can abort the process instance by sending an abort signal. In this case, the process instance will be terminated as aborted (not done).

Behavior of the State Machine

Depending on the BPMN Element you have added your execution implementation to, the process state machine shows a different behavior.