Quick intro to handling Error in Mule 4

In MULE 4 when a event is processed Messaging errors happens within the flow when there is some kind of processing issue and the flow execution stops. This post explains how messaging errors are handled and how the error objects are created when a Messaging Error occurs. These Error Objects and are handled with error handler. Each error handler contains one or more error handler scopes. Each error scope can contain many number of event processors.

In mule error is defined by an error object and has two properties:

— error.description: a string that provides a description regarding the problem.

— error.errorType: an object used to characterize the problem and allow routing within an error handler defined by namespace and identifier. (see Fig 1.)

Each errorType has a parent. VALIDATION:INVALID_BOOLEAN has VALIDATION:VALIDATION as the parent which has MULE:VALIDATION as the parent. The listener can also be configured to respond error description (see Fig 2).

Fig 1: Nomenclature of  Mule error Object

In the http listener (Fig. 2) change the error options under Response tab to error.description that way the response will give an idea of the error generated.

Application level error 

 In a Mule applications  implements a fail-safe in case an error is thrown in the flow and it wasn’t been able to be caught anywhere within the application. This is referred to as application level error handling and can be implemented two ways:

(a) Mule Default Error Handler: If no error handler is defined then Mule default error handler is used which implicitly and globally handles all messaging errors thrown in the application. It stops the application and logs the error. 
(b) Global Error Handler: The Global Error Handler can be configured to process errors and can be customised, therefore you can put an On-Error Propagate or an On Error Continue scope in the global error handler.

The global error handler is usually configured in global.xml with global configuration (Fig 3a). In this example an On error continue is used. Once the listener is triggered the payload is set to ” success begin main flow” (Fig 3a). The “Is number” validator throws an error.  The error is handled by global error handler since there is no error handler scope in the flow. On Error Continue scope handles the error and set the payload to  “Error – Main Flow”.  A success 200 response is returned (Fig. 3b)

Flow level error handler 

Handling errors at the application level is a good approach but often flows need specific logic to handle errors when an error happens within the flow (i.e. reprocessing logic, error logging, etc). In Mule 4 deals this with by allowing specific error handling logic within each of the flows. There are two error handling scopes in Mule 4 (a) On Error Propagate (b) On Error Continue.

On error continue: 

• All the processors in the error handling scope are executed.
• At the end of the scope the rest of the flow that threw the error is not executed.The event is passed on to the next level as if no error was generated.
• HTTP listener returns success response.

Once the listener is triggered the payload is set to ” success begin main flow” (Fig 4a). The “Is number” validator throws an error.  The On Error Continue scope handles the error and set the payload to  “Error – Main Flow”.  A success 200 response is returned (Fig. 4b)

On error propagate:

• All the processors in the error handling scope are executed.
• At the end of the scope the rest of the flow that threw the error is not executed. The error is rethrown at the next level and handled there.
• HTTP listener returns error response.

Once the listener is triggered the payload is set to ” success begin main flow” (Fig 5a). The “Is number” validator throws an error.  The On Error Propagate scope handles the error and but does not set the payload to  “Error – Main Flow” but rethrows the error.  An error response of 500 response is returned (Fig. 5b) describing the error along with the payload.