Error Handling in Mule 4
In this tutorial, we will learn about various types of error handling in Mule 4 and how we can implement it in our project with an example.
Join the DZone community and get the full member experience.
Join For FreeIn this tutorial, we will learn about various types of error handling in Mule 4 and how we can implement it in our project with an example.
There are 3 types of error handling mechanisms in Mule 4.
- On-Error Continue
- On-Error Propagate
- Try Catch Scope
On-Error Continue
On-Error Continue catches the error and does not report it as an error, thus the processing of the flow continues even after the error has occurred. This error handler can be used in flows where you don’t want to stop the flow processing even if an error has occurred.
For example, in the below flow, the parent flow will execute till the end even if web consumer has returned an error.
SchedulerFlow is calling the callWebService flow, and in case of any errors at point 9 (at web service consumer), the flow will process as follows: 1->2->3->7->8->9->12->13->4.
At point 13, the error is sent to its parent flow (SchedulerFlow) as a flow message, and the parent flow executes its processing further.
On-Error Propagate
On-Error Propagate works exactly as the Mule 3 Catch exception strategy. In case of any errors, On-Error Propagate processes the error message and re-throws the error to its parent flow. No further processing is done on that particular flow.
For example, in the below flow, when flow execution starts, points 1, 2, and 3 will execute first. On-error at point 3, the error is caught by on-error propagate and error processing begins with point 6, 7; once the error handling flow is completed, the flow processing ends and an error is re-thrown to its parent flow.
In case of no error or a happy scenario, points 1, 2, 3, 4, and 5 are executed. In case of an error at point 3, points 1, 2, 3, 6, and 7 are executed.
In the second example below, SchedulerFlow is calling the callWebService flow, and in case of any errors at point 9 (at web service consumer), the flow will process as follows: 1->2->3->7->8->9->12->13->5->6.
Here at point 13, the error is thrown to its parent flow (SchedulerFlow), and the parent flow error handler is invoked.
Try-Catch Scope
Try-catch scope can be used within a flow to do error handling of just inner components. Try-catch scope can be very useful in cases where we want to add a separate error processing strategy for various components in the flow.
For example, in case of an error at point 3 (at web service consumer), the flow will process as follows: 1->2->3->7->8->10->11.
In case of an error at point 5 (at salesforce's connector), the flow will process as follows: 1->2->3->4->5->9->6.
Configuring On-Error Continue and On-Error Propagate
In Mule 3, we had to specify which error is to be caught inside the catch exception strategy. We can do it in Mule 4 with even more control.
In Mule 4, we can specify Error Type and/or When Condition, which, when it is evaluated true, that particular error handler is executed. In case no error handler catches the error, the error is re-thrown to its parent flow.
Error Type: This matches the type of error that is thrown. Error Type is auto-populated based on connectors used in the flow. It contains the list of errors that the connectors can throw in the flow.
When Condition: The expression will be evaluated to determine if the exception strategy could be executed. This should always be a boolean expression.
In the below example, when the errorCount variable is greater than 3, then only that particular error handler is invoked.
Let me know your thoughts in the comments.
Opinions expressed by DZone contributors are their own.
Comments