Improvements to exception handling for Mule 3
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
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.
Hassan Sajjad
September 11th 2010
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
Travis
September 16th 2010
Both of those should be handled by the Service exception strategy in Mule 3, since there is a message involved.
Hassan
September 1st 2011
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.
Thanks
Michael Bruton
April 18th 2012
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.
Michael Bruton
April 19th 2012
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: http://forum.mulesoft.org/mulesoft/topics/how_to_handle_exception_from_outbound_endpoint
This helped me a great deal.