MuleSoft provides various ways to handle exceptions. Faults in Mule are generally referred to as exceptions. Mule exceptions can be divided into two categories:
System exceptions are generally invoked when the exception is thrown at system level (i.e., when no message is invoked). This type of error occurs during application startup when there is a connection failure with external systems — i.e., let's say Mule is trying to establish a connection with a JDBC database to fetch and read messages. If the connection fails, Mule invokes the system exception strategy.
Messaging exceptions are generally invoked when the messaging exception strategy is thrown into the flow.
We will focus on messaging exceptions in this article. Mule provides various exception strategies.
Catch Exception Strategy
The catch exception strategy catches all of the exceptions within the parent flow and processes them, overriding the default exception strategy. Further, you can use the catch exception strategy to:
Avoid propagating exceptions to inbound connectors.
Avoid propagating exceptions to parents via flow reference components.
Ensure that the transaction processed by the flow will not roll back when the error occurs.
Reference Exception Strategy
You can create one or more global exception strategies in your Mule application to reuse in your flows. First, create a global exception strategy, then add a reference strategy exception to the flow to apply the error-handling behavior of your new global catch exception strategy.
Choice Exception Strategy
You can define the choice exception strategy to customize how Mule handles the message that throws the exception based on the message's exception type at the moment it throws the exception.
Choice exception strategy contains one or more exception or rollback strategies.
Choice exception strategy cannot be nested with other choice exception strategies.
Any Mule expression evaluator can be used as the expression attribute of an exception strategy.
Rollback Exception Strategy
You can define the rollback exception strategy to ensure that the message throws an error in the flow that can be rolled back for re-processing.
Rollback exception strategy can potentially create an infinite loop during message failure. The rollback exception strategy catches the error and rolls the message for reprocessing; the message throws error again; the rollback exception strategy rolls the message again for reprocessing; and so on.
To avoid this infinite loop and responsibly manage unresolvable errors, you can apply two limitations to a rollback exception strategy:
Define the maximum number of times that the rollback exception strategy attempts to redeliver the message for processing.
Define a flow to handle messages that exceed the maximum number of redelivery attempts.
There are various ways to define the messaging exception strategy within a Mule application.
Define Error Handler Within Mule flow
You can define the exception strategy within a flow and it will not be referenced by other flows within the Mule application.
Define 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) using reference flow strategy.
Define Custom Default Global Error Handler
You can define custom default global error handlers that will become the default error handler for your flows within the Mule application unless one of the above options is used in the flow.
I hope that this article on exception strategies using MuleSoft Anypoint Studio is helpful!
Here is the video tutorial.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}