Error Event

Introduction

An error event defines where a microflow will stop and throw an error that occurred earlier. If you call a microflow, you may want to know whether any errors occurred within the microflow or not. This event throws the error again, so the caller of the microflow can catch them. You can control whether all database actions within the current transaction will be rolled back.

For more information on error handlers and their settings in microflows, see the Error Handlers subsection of Handling Errors in Microflows, below. More information on error handlers and their settings in nanoflows is in the Error Handlers subsection of Handling Errors in Nanoflows, below.

Link an error event and an activity which has an error handlers set on it with a sequence flow.

In this example, an error occurs while committing an object to the database. It is caught, and the flow continues to the error event where the error is passed back to the caller of the microflow. So you can implement your error handling on multiple levels.

Handling Errors in Microflows

When an error occurs in a microflow, all changes that have been made to objects are rolled back and the microflow is aborted. Optionally, you can handle errors in the microflow itself by configuring different error handling settings. You can even inspect the details of the error by looking at the predefined objects $latestError and $latestSoapFault.

Error Handlers

An error handler can be set on a microflow activity, decision, or loop.

On an activity or decision, you have three options:

• Rollback (default)
• Custom with rollback
• Custom without rollback

For the latter two options you can draw an additional flow from the block and mark this flow as the error handler flow. When selecting ‘Custom with rollback’ it will trigger this path when the error occurs and still rollback your objects afterwards. The ‘Custom without rollback’ option does not rollback the objects. After you selected a flow as the error handler it will show this as in the following image. Error handling is only specified for an individual action. The “without rollback” in the Custom without rollback option is only targeted at the action itself, not the error handling. There is thus a slight difference between Custom with rollback and Custom without rollback throwing the same exception or another one in the error handler. In the latter case, you will still have access to the database objects you have created until the end of error handler.

On a loop you get two options:

• Rollback (default)
• Continue

The continue option means that when an error occurs, the loop will simply continue to the next iteration. It will show as a continue icon on the exit flow of the loop.

Inspecting Errors

When an error occurs inside a microflow, under the hood a Java exception is raised that contains information about the error that occurred. Inside a custom error handler (as in, after an error handling flow), you can inspect the type of this Java exception as well as several other properties. Every microflow contains two predefined error objects, $latestError and $latestSoapFault. $latestError is an object of entity System.Error, while $latestSoapFault is an object of entity System.SoapFault, which is a specialization of System.Error.

In a custom error handler that is executed after an error occurs, $latestError is set to an object containing information about the error that occurred. If the error is a SOAP fault (an error that occurs as a result of a web service call), $latestSoapFault is set to an object that contains more specific information about the SOAP fault. Otherwise, $latestSoapFault is empty.

The following table shows the attributes of System.Error and System.SoapFault.

Click here for more information on SOAP faults.

Handling Errors in Nanoflows

When an error occurs in a nanoflow, the changes that were made to objects are not rolled back and the nanoflow is aborted. Optionally, you can handle errors in the nanoflow itself by configuring an error handler. You can inspect the details of the error by looking at the $latestError predefined variable.

Error Handlers

Error handlers are supported on all nanoflow elements except for gateways and loops. There are two error handler options:

• Abort (which is the default)
• Custom without rollback

With the Custom without rollback option, you can draw an additional flow from the block and then mark this flow as the error handler flow. The Custom without rollback option does not roll back the objects. After you select a flow as the error handler it will appear this way:

Error Inspection

In a custom error handler executed after an error occurs, the $latestError variable is set to the message of the error information. The $latestError variable type is String, unlike in microflows where errors’ type is the System.Error entity.

The $latestSoapFault variable is not available in nanoflows.