Reading Time: 5 minutes

Background

You may recall that in Mule 2.x, there were two places where you could configure exception handling strategies: 1. on the service 2. on the connector

Since the service receives events from endpoints which depend on the connector, and transformers are a grey area, it turned out that this scheme was very confusing, because it was never clear which strategy was going to handle which exception, and in some cases the same exception was even handled by both strategies!

Concept

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

For Mule 3, we have tried to simplify and improve our approach to exception handling. There are basically two scenarios for exception handling in Mule:

1. A message is in play – e.g., a routing or transformer exception
2. No message is in play – e.g., a connection exception or an initialization issue

#1 we are calling Messaging exceptions, and have defined the following interface:

Note that the exception handler receives the MuleEvent which was being processed when the exception occurred. Based on this context information, some appropriate action can be taken (re-route the message, send it to a dead letter queue, correct its payload, etc.). The MuleEvent returned by the exception handler will be routed on to any remaining steps in the flow (this will generally have payload = null and exceptionPayload containing the exception).

#2 we are calling System exceptions, and have defined the following interface:

Since there is no message in play here, no MuleEvent is received nor returned by the exception handler.

The Messaging exception strategy is configured on a service or a model (which applies to all services within the model), the same as in Mule 2.x. This will handle any exceptions where a message is in play.

The System exception strategy is configured on the MuleContext, and is a single strategy for all exceptions where a message is not in play. This should be sufficient because if there is no message in play, there is not much you can do in an exception handler anyways other than log and notify that the exception occurred.

These changes will make exception handling behavior more predictable and robust for Mule 3.

Configuration

As in Mule 2.x, a Service exception strategy can either be configured on a Service:

or on a Model, in which case it applies to all Services in that Model:

For more information, refer to the Mule 3 Documentation.