Reading Time: 6 minutes

Mule provides different approaches to handling errors. You can set exception strategies for connectors, models, and individual services. You can use the exception router to specify where the message goes when an error occurs. And you can use the exception type filter for fine-grained control. Following is an introduction to these approaches.

Exception Strategies

latest report
Learn why we are the Leaders in API management and iPaaS
Read reports

Exception strategies are used to handle exception conditions when an error occurs during the processing of a message. Exception strategies are used by components and connectors. You can set exception strategies in the following places:

  • On the connector to set a common exception strategy for all endpoints that use the connector
  • On a model to set a common exception strategy for all services within that model
  • On a service to set an exception strategy for the components within that service.

Exception strategies set on the service or the model are used to handle component exceptions. These are exceptions that occur during the processing of a message through Mule and include all exceptions other than system exceptions such as initializing/disconnecting connections. Typically, you customize the exception handler to control how component exceptions are logged and routed.

Exception strategies set on the connector can be considered as fallback exception strategies that catch exceptions that occur before the connector has started or for connectors that haven’t got an association with a service and therefore cannot use a service exception strategy. Typically, you can’t do much more than log these exceptions. Therefore, you do not need to customize connector strategies, but you can configure them to route exceptions to a common error queue.

For more information on exception strategies, see Error Handling in the Mule User’s Guide (login required, but registration is free and only takes a moment).

Exception-based Router

When an exception occurs, the exception-based router determines where the message goes. You can have multiple endpoints specified on the exception-based router, so that if the first endpoint fails with a FatalConnectionException, the next endpoint is tried, and then the next. If all endpoints fail, a routing exception is thrown. Note that the exception-based router will override the endpoint mode to synchronous while looking for a successful send, and it will resort to using the endpoint’s mode for the last item in the list.

Following is an example of configuring the exception-based router:

<outbound>
  <exception-based-router>
    <tcp:endpoint host="10.192.111.10" port="10001" />
    <tcp:endpoint host="10.192.111.11" port="10001" />
    <tcp:endpoint host="10.192.111.12" port="10001" />
  </exception-based-router>
</outbound>

For more information, see Using Message Routers in the Mule User’s Guide.

Exception Type Filter

You can use the exception type filter to gain fine-grained control over messages that produce errors. For example, assume you want a synchronous flow where the message is sent to a validation service, and then if it fails validation, the message and its exception are forwarded to another service AND the message and its exception are returned to the caller. You could achieve this using a chaining router and the <exception-type-filter> as follows:

<chaining-router>
  <vm:outbound-endpoint path="ValidationService" synchronous="true"/>
  <vm:outbound-endpoint path="ValidationError" synchronous="true">
    <exception-type-filter expectedType="java.lang.Exception"/>
  </vm:outbound-endpoint>
</chaining-router>

For more information on filters, see Using Filters in the Mule User’s Guide.