Mule Error Handling 101

Error handling in MuleSoft integration solutions is a topic that must be addressed to produce robust applications. When using Mule ESB for developing your solutions, error handling is a relatively easy thing to do. There are however a few tips on Mule error handling that everyone should know.

The Basics

There are two different types of errors that can occur in Mule:

1. System Exceptions - This is when no message is involved. Ie; An error on application startup
2. Messaging Exceptions - This is when there is an error within a flow

This article will focus on #2, Messaging Exceptions. What does Mule provide out of the box? If you do not implement custom error handling with Mule, there is default error handling. This default error handling will rollback a transaction if there is one, and will log the exception. What if I want to implement custom error handling?Within your Mule application, you can do the following:

1. You can define an error handler within a flow
2. You can define a global error handler that can be referenced from your flows
3. You can define a custom default global error handler that will become the default error handler for your flows, unless you do either of the above options

Let's discuss these three options in more detail:

1. Define an Error Handler Within a Flow

You can define error handling that is encapsulated within a single flow and is not referenced by other flows in your application. This would look something like this: <flow name="sampleFlow" doc:name="sampleFlow"> <http:inbound-endpoint address="${main.inbound.http}" doc:name="HTTP" /> <catch-exception-strategy doc:name="Catch Exception Strategy"> ... do something </catch-exception-strategy> </flow> To Note: Normal flows can implement or refer to a global error handler, private flows inherit the parent error handler, but can define a different error handler to use, and sub-flows only can inherit the error handler of the parent/calling flow.

2. Define a Global Error Handler

You can define a global error handler that can be referenced from any flow (except sub-flows, which inherit the calling flow error handler). This would look something like this: <catch-exception-strategy name="testGlobalErrorHandler" doc:name="Catch Exception Strategy"> ... do something </catch-exception-strategy> <flow name="sampleFlow1" doc:name="sampleFlow"> <http:inbound-endpoint address="${main.inbound.http}" doc:name="HTTP" /> <exception-strategy ref="testGlobalErrorHandler" doc:name="Reference Exception Strategy" /> </flow> <flow name="sampleFlow2" doc:name="sampleFlow"> <http:inbound-endpoint address="${main.inbound.http}" doc:name="HTTP" /> <exception-strategy ref="testGlobalErrorHandler" doc:name="Reference Exception Strategy" /> </flow> To Note: You can define as many global exception strategies as you want to use within your application flows.

3. Define an Custom Default Global Error Handler

You can define a global exception strategy that can be designated as a custom default global error handler. This would look something like this: <catch-exception-strategy name="testGlobalErrorHandler" doc:name="Catch Exception Strategy"> ... do something </catch-exception-strategy> <configuration defaultExceptionStrategy-ref="testGlobalErrorHandler" doc:name="Configuration" doc:description="Use as implicit default exception strategy."/> <flow name="sampleFlow1" doc:name="sampleFlow"> <http:inbound-endpoint address="${main.inbound.http}" doc:name="HTTP" /> </flow> <flow name="sampleFlow2" doc:name="sampleFlow"> <http:inbound-endpoint address="${main.inbound.http}" doc:name="HTTP" /> </flow> <flow name="sampleFlow3" doc:name="sampleFlow"> <http:inbound-endpoint address="${main.inbound.http}" doc:name="HTTP" /> <catch-exception-strategy doc:name="Catch Exception Strategy"> ... do something </catch-exception-strategy> </flow>

To Note: In the above example, sampleFlow1 and sampleFlow2 would use the global default error handler, and sampleFlow3 would use the embedded error handler.

In Conclusion There are a lot of options to consider for error handling in your Mule applications. The good news is that the implementation of these error handlers is fairly straightforward and easy to implement. I hope this helps in your understanding of error handling in MuleSoft development and that you can use these techniques in your applications. To Note: In the above examples, the catch exception strategy was hi-lighted. There are several other options for error handling that can be reviewed and utilized in the link provided below. For more information about Mule error handling, please view the current documentation at: http://www.mulesoft.org/documentation/display/current/Error+Handling