LOUISVILLE, KENTUCKY
ATLANTA, GEORGIA
CHICAGO, ILLINOIS
CINCINNATI, OHIO
DENVER, COLORADO
MADISON, WISCONSIN
RARITAN, NEW JERSEY
TORONTO, ONTARIO
NOIDA, INDIA
HYDERABAD, INDIA

V-Soft's Corporate Headquarters

101 Bullitt Lane, Suite #205
Louisville, KY 40222

502.425.8425
TOLL FREE: 844.425.8425
FAX: 502.412.5869

Denver, Colorado

6400 South Fiddlers Green Circle Suite #1150
Greenwood Village, CO 80111

TOLL FREE: 844.425.8425

Chicago, Illinois

208 N. Green Street, #302, Chicago, IL 60607

TOLL FREE: 844.425.8425

Madison, Wisconsin

2810 Crossroads Drive, Ste. 4000
Madison, WI 53718

TOLL FREE: 844.425.8425

Atlanta, Georgia

1255 Peachtree Parkway Suite #4201
Cumming, GA 30041

TOLL FREE: 844.425.8425

Cincinnati, Ohio

Spectrum Office Tower 11260
Chester Road Suite 350
Cincinnati, OH 45246

Phone: 513.771.0050

Raritan, New Jersey

216 Route 206 Suite 22 Hillsborough Raritan, NJ 08844

Phone: 513.771.0050

Toronto, Canada

1 St. Clair Ave W Suite #902, Toronto, Ontario, M4V 1K6

Phone: 416.663.0900

Hyderabad, India

Incor 9, 3rd Floor, Kavuri Hills
Madhapur, Hyderabad – 500033 India

PHONE: 040-48482789

Noida, India

H-110 - Sector 63 ,
NOIDA , Gautham Budh Nagar ,
UP – 201301

Understanding Error Handling in MuleSoft Mule 4

MuleSoft professionals working on Mule4 error handling

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:

Error-Handling Process in Mule 4 Figure: User Defined Error Handling flow

Flow  Error Continue and On Error Propagate Scope Mule 4

 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.

Default Error Handling Process in Mule 4
                                       Figure: Default Error Handling Flow

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.

Error Handling with the Try Scope Mule 4

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.

New call-to-action

Topics: MuleSoft, Mule4, Error Handling in Mule 4, Mule 3

Get tech and IT industry Updates

A Comprehensive Guide to MuleSoft Mule 4