IBM BPM, V8.0.1, All platforms > Create processes in IBM Process Designer > Modeling processes > Modeling events > Handing errors using error events
Handling errors in services
For services, you can use error intermediate events to catch errors, and you can use error end events to throw errors.
Usage of error events in services Service event Description error intermediate event attached to the boundary of a step Catches errors from the step error intermediate event as part of the service flow Catches all errors raised by steps of the service flow that are not handled by an error intermediate event at the boundary of a step. This event can have only outbound links. error end event Throws an error and ends the processing of this service. You might, for example, use an error end event when you want a particular result from a Coach to end a human service. To determine whether to use error events in your services, consider the following points:
- You must attach error intermediate events to steps in your service.
- Include error intermediate events in the service flow so that they can act as global error handlers in the service.
- Determine whether errors can be handled immediately, and normal processing can be continue, or if another error can be thrown at another level. Then implement error handling from the bottom up.
- Use an error end event to throw a specific error. You can specify an error code and error data for the error.
- Consider specifying the error data to catch specific errors.
For example, you could filter on the error code for the types of errors that are caught and map the error code to a variable after the errors are caught. When all errors are caught, or if only an error code is specified, the error data is captured in an XMLElement in the tw.system.error variable.
When building services that include integrations with external systems or other implementations, use error intermediate events when it is possible to handle errors that are raised by steps in the service. Be sure to include the appropriate logic and a error end event in your services to throw errors when they still exist after attempts to handle them. Throwing the errors ensures that the errors are passed to parent processes and services and can be handled at a higher level.
For example, the following image shows a service that catches an error for a database query, attempts to handle the error with a special script, and then throws the error for further processing by higher level services or processes if the handler script fails.