As an integration developer and architect, I am currently working on many integration projects where we have implemented business flows and have faced challenges, data validation errors, external systems unavailability, and system failures. Not handling these errors correctly and swiftly can cause a considerable impact on our projects and it may show a stack trace that makes the attacker’s job significantly easier. Additionally, if the system is down or credentials have expired, we wouldn’t know whether the code is working properly.
When code is executed, there could be errors like expired credentials, SSL failures, errors in authentication and authorization, underlying system connectivity errors, or data validation errors. MuleSoft’s error handler catches errors and allows us to write code for error handling strategies to handle errors effectively.
In this post and the upcoming series, I will share six error handling strategies for Mule 4 and their use cases.
Mule 4 error types: System errors and messaging errors
Within Mule 4, we see two types of errors: system errors and messaging errors.
System errors happen when an error occurs during deployment due to an external system’s unavailability. They occur during application startup where the Mule event is not involved. Error handling does not handle system errors.
Messaging errors occur while the Mule app is running. They occur due to external connectivity, business data validation, or executing processors where the Mule event is involved. An error handling strategy handles messaging errors.
The Mule 4 runtime is based on event-driven architecture (EDA). This means that, for a flow to run, an event must be triggered. At every processor inside the Mule flow, we have a Mule event which consists of payload, attributes, and variables. The Mule event also has an error object which is helpful to retrieve more information from the exception, such as the error cause or any inner errors.
Components of a Mule 4 error
There are specific components in the error object that help us to retrieve the error details.
- #[error.description] – A description of the problem.
- #[error.detailedDescription] – A description of the problem. This can potentially be the same or more extensive than the description.
- #[error.errorType] – A type that is used to characterize the problem and allow for routing within an error handler.
- #[error.cause] – The underlying Java Throwable that resulted in the failure.
- #[error.childErrors] – An optional collection of inner errors, used by elements like Scatter-Gather to provide aggregated route errors.
- #[error.errorMessage] – An optional Mule message about the problem.
In the image above, we can see the “HTTP:CONNECTIVITY” error. We can get to the error’s root cause and find additional information to resolve the error with the Mule error component.
Log and propagate an error with MuleSoft’s default error handler
Now that we have covered the two error types and we understand how errors are triggered, I’ll cover error handling provided by MuleSoft’s runtime. If we don’t have any error handling code, MuleSoft’s runtime provides the default error handling. It logs the error and propagates it.
Below are the main points we need to know about the default error handler:
When an error occurs at the HTTP Request component, the error handling stops the processing of the flow and transfers the error to the default error handler, which logs and propagates the error. The default error handler is provided by the Mule runtime and it will catch the error when there is no error handling defined in the flows.
MuleSoft provides two types of handlers that do the processing based on our requirements: On-Error Continue and On-Error Propagate. An On-Error Continue component handles the exception and doesn’t rethrow errors to the parent flow or error handler. An On-Error Propagate component handles the exception and then rethrows it to the parent flow or error handler.
Now you know the anatomy of a Mule event and where the error object is located, the two types of errors (system and messaging), how the default error handler works, and the difference between the On-Error Continue and On-Error Propagate components.
In the next part of this series, I will be covering more Mule 4 error handling tips including multiple use cases and scenarios, On-Error Continue and Propagate combination in parent and child flow, and reference and global error handling.
To see more details about the selector expressions, please go to the official MuleSoft documentation.
