Handling errors in client-side human services

You can handle errors in a client-side human service by using a stand-alone error event handler or you can catch errors at a particular step by attaching a boundary error event to an individual service. To throw specific errors and end the processing of the service at a specified step, you can use error end events.

To catch errors, you can use either error boundary events or error event handlers. Both options provide the same capability to catch errors. The difference is where the error handling logic resides in your diagram and the scope of the errors that are caught.

An error boundary event catches errors that are thrown from the service it is attached to. It can be attached either to a called service node or to a nested client-side human service node.
An error handler catches errors that are thrown from the client-side human service and all its nested services.

You can configure boundary events and error event handlers to catch all errors or specific errors. At run time, boundary events take precedence over error event handlers and specific errors take precedence over catch-all errors.

You can specify error properties to catch or throw specific errors, filter on the error code for the types of errors, and map to a variable after the errors are caught.

The error event information is captured in the tw.error.code and tw.error.data variables. For more information, see JavaScript API for client-side human service development.
By mapping the error event to a variable, events with incompatible data types are filtered out and the data is captured in a local variable.

User-defined and system-defined errors

Specific errors that an error event handler catches can include user-defined errors that are thrown from the model hierarchy, namely, from the services or client-side human services that have an error end event, or system-defined errors. The error code options for system-defined errors are:

BPMBOSaveFailedError: Catches errors from a shared business object save service
BPMTaskOwnerError: Catches errors that occur when the ownership of a task is withdrawn from the current user

As an example, a system-defined error could be a task-ownership error that occurs at run time, when an interactive task that a Process Portal user performs in a user interface is reassigned from an external source to another user. An external source can be, for example, another service or a reassign REST API call. After the task is reassigned, the current user (the former task owner) receives an ownership error when his work on the task triggers an interaction with the server. To enable the user to gracefully handle the error, in the underlying client-side human service for the specified user interface, you can implement an error event handler that catches the specific error and provides the logic that displays the error.

Note: Errors from client-side script activities are not handled through error event handlers. Typically, an error from a client-side script activity results in an error message in the coach window. You can use the browser debug tool to fix the issue. Using try/catch blocks in your JavaScript code is also good practice for troubleshooting.

Table 1. Usage of error events in client-side human services
Icon	Error event	Description
	Error boundary event. An intermediate error event that is attached to a service node in a client-side human service	Catches errors and receives error data from the service to which it is attached. To model where the client-side human service resumes after it catches an error, you connect each error boundary event to an activity that runs the error handling logic. You can wire an error boundary event to any node. You can attach error boundary events either to a called service node or to a nested client-side human service node. You can reposition the error boundary event along the service boundary. You can remove it from the service or you can move it to another service. Shortcut key: B For more information, see Catching errors by using error intermediate events.
	Global error event handler that catches errors in the client-side human service and runs error handling logic	Catches all errors or specific errors. It can be used as a stand-alone event handler outside a service. You implement the error handling logic in the error handler. You can use multiple error event handlers in a client-side human service. For example, you can configure an error event handler to catch a specific error code and an error event handler that catches all other errors. You can then implement different logic to handle specific errors and logic to handle all other errors. An error event handler that is used in a nested client-side human service catches errors from the service in which it is defined and from all the nested services below it. For more information, see Catching errors by using error event handlers.
	Error end event that throws an error and ends the processing of the client-side human service in which it is implemented	Throws a specific error and ends the processing of the client-side human service in which it is implemented. You can connect an error end event to any node in a client-side human service. You can specify an error code and error data for the error. For more information, see Throwing errors by using error end events.