Understanding Error Handling in MuleSoft Mule 4

Compared to MuleSoft's Mule 3, the latest release, Mule 4 has some exciting features to offer to businesses to improve connectivity. Businesses are starting to utilizing the abilities of the Mule 4 in order to stay ahead of their competition. To handle better error mechanisms in Mule 4, here we discuss how Mule 4 comes with an integrated and effective error handling approach.

Error Handling in Mule 4

Unlike Mule 3 exception handling in Mule 4 is not Java styled exceptions. Mule 4 error handling framework directly handles the exception by having integrated and configurable error handling mechanism. Instead of completely avoiding the Java exceptions handling mechanism, Mule 4 abstracts Java exception objects right into the Mule 4 error objects. In throwing errors instead of Java exceptions validators are used which include:

1. Description – a string
2. ErrorType – an object
3. Cause – the underlying Java Throwable objects that caused the failure

The errors are located and handled - based on type - during the design phase. The problem with the Mule 3 approach is it's mandatory to go through the complete code to understand, either to plan the error handling or to locate the cause of any execution failure. The programmers can pre-define the complete error handling block to configure better. A well-defined error handling block includes:

• Description: Designates issue.
• Type: Exemplifies problem. Namespace and identifier indicate the type of error. Each error type has a parent and by default, ANY is the parent type for any error.
• Cause: Indicates the cause that triggered the execution failure.
• Error message: Communicates and makes the error message more clear.

Whenever an error occurs the natural Mule execution flow halts and an event is raised and passed to the error handler. The error handler component can contain any number of internal handler scopes defined within it. Each internal error handler scope can have many event processors. On-error-continue and on-error-propagate are the internal error handlers. As the event is passed to each error handler, the appropriate internal error handler is identified and directed to it. The detailed flow of user-defined error handler is illustrated in the below figure:

 Figure: User Defined Error Handling flow

 Figure: Flow of on Error Continue and On Error Propagate Scope

Default Error Handling

If the error handler is undefined, inherently the default Mule 4 error handler takes care of error handling, offering no configurability options. To increase the visibility of the error it is suggested to define the error handling block.

Try  

Mule 4 has introduced “Try” to get a hold of errors of any number of event processes during the flow itself, thereby avoiding the need for creation of another flow. This way Mule 4 ensures uninterrupted and smooth processing. The beauty of Try scope is it envelops a number of error event processors prior to handling any exceptions. As the error handling strategy is more inline, this eliminates having to define multiple new error flows for each error event process. As there is no need to extract each error flow separately, the error handling flow costs and time are optimized.

Figure: Error Handling with the Try Scope

To Summarize

1. Mule 4 abstracts the Java exception into Mule 4 error objects
2. There is a hierarchy that can be used to catch groups of error objects together in Mule 4
3. We can map Errors with a custom Error object to differentiate errors at different locations of the application
4. Try scope allows micro-control of message processing inside the flow

To learn more about the technical details of new Mule 4 features or about the Mule 3 to Mule 4 migration process, get a free consultation from our Mulesoft experts.