We all love the “Happy Path”, but what to do when our applications fail? Errors, errors everywhere, and that is no fun at all. Building applications with error handling is a must to follow best practices. If you, too, find error handling to be very challenging, you are not alone. It is like the saying, How do you eat an elephant? One bite at a time. So, how do we demystify error handling? One byte at a time!

Mule 4 error handling can be very challenging.

To master the art of Handling Errors, we must first demystify Mule 4 error handling. Take these perplexing topics and break them down. Many times, after teaching Error Handling to learners for the first time, they are overwhelmed. So, we will begin with the basics of error types, error handling scopes, the behavior of the HTTP default settings, and overriding those settings. As we work with a basic flow, we will see these concepts in action.

Your next step after reading this blog is to get hands-on experience, which will strengthen your skills in the basic behavior of the various error scopes. Create the example flows used in the blog, or they can be downloaded from here. Deploy and test each of the examples to predict the results of each scenario. Now, let’s take a look at the types of errors we will encounter.

Error Types

There are two types of errors: System errors and Messaging errors.

System errors are errors that are thrown at the system level, for example, during an application startup or a failed connection to an external system. This error type cannot be handled within a Mule flow other than setting a reconnection strategy.

Messaging errors are errors that are thrown within a Mule flow, for example, invalid data or bad requests while processing a flow and we are able to handle these errors. In this case, the flow execution stops, if an error handler scope is present, the Mule event is passed to it. Any processors within the error handler scope are executed according to the error handling strategy. If no error handler scope is present, the Mule default error handler is invoked, which does not allow any error handling strategy to be executed. Let’s look at the behavior of the Mule default error handler.

Mule default error handler example

This is a simple flow that uses the Raise error processor to throw an error. Download this entire project from here.

Notice there is no error handling scope in the Error handling area of the flow. When the error is thrown, the Mule default error handler is invoked. The flow stops, an HTTP error response is returned with a 500 Server Error and the Error description. Why is this, do you know?

Response to the client is:

The Error Object is created.

When an error is thrown, an Error Object is created. Two elements in the error object that we will focus on is the Error Description and Error Type.

Component	Description	Expression
Description	A description regarding the problem.	#[error.description]
Type	A Type used to characterize the problem and allow routing within an error handler.	#[error.errorType]

HTTP Listener default response settings

To understand the response the client received, let’s observe the HTTP Listener default settings.

● If the response is a Success, a 200 HTTP Success status code and the payload is returned.

● If there is an error, the error response is a 500 Server Error and the error description is returned.

● To answer the question above: Why is this, do you know? It is due to the HTTP default error response settings.

● We will override these settings in Part 2: Mule 4 error handling deep dive

Error handling scopes

There are two error handling scopes that we can use to handle errors, but both behave very differently.

On Error Propagate means a Mule Error Object is being passed.
On Error Continue means a normal Mule message is being passed.

Let’s take a look at the behavior of both scopes.

On Error Propagate

The On Error Propagate scope is added to the example flow. When the error is thrown, the On Error Propagate scope is executed with the two processors inside.

● Run the example in debug mode, you will see those processors are invoked.

● Set payload is set to “Status: Error Occurred!”

● The logger displays the payload value in the console.

Since the scope is On Error Propagate, the Mule Error Object is passed to the HTTP error response and the client receives 500 Server Error and the error description.

On Error Continue

The On Error Continue scope is added to the example flow. When the error is thrown, the On Error Continue scope is executed with the two processors inside.