Improvements to exception handling for Mule 3

September 10 2010



You may recall that in Mule 2.x, there were two places where you could configure 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!


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.


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.

We'd love to hear your opinion on this post

5 Responses to “Improvements to exception handling for Mule 3”

  1. What’s the fate of the following 2 scenarios in Mule 3:
    a) transport level dispatch err
    b) transaction commit time err

    Pls clarify. Thx

  2. Both of those should be handled by the Service exception strategy in Mule 3, since there is a message involved.

  3. Can you also show an example of configuring:

    a) A Global Exception Strategy for the Flow based Mule config, having multiple (>1) flows.
    b) For System Exceptions, sample XML config showing how to configure this on the Mule Context. Please provide sample that applies to both types of supported syntaxes in Mule 3 – Flow and legacy Service config. The strategy can trigger some alerting mechanism e.g. send a mail when a System error is caught.


  4. I would also like to see how to configure a handler for the System Exceptions, as Hassan outlines above. I am particularly interested in being able to send a notification to Application Support in our company. In Mule 2 I put exception strategies on connectors and performed notification when those exceptions occurred. I am converting to Mule 3 and I am losing this functionality.

  5. Actually, Alexander Volkov detailed how to configure a System Exceptions handler here in his response to the “How to handle exception from outbound-endpoint ” posting:

    This helped me a great deal.