Mule 4 Error handling concept is totally different from Mule3. As like Mule3 we don’t have any Exception strategies. Instead we have SCOPE in Mule4.

In Mule 4 we have to know about the below concepts :

When a Mule flow execution fails, it produce errors.

Mule Errors are group in to Error Types which has a hierarchical order like Java Throwable class.

To use the Mule4 error framework, it provide some expressions.

• Expressions to handle Mule Errors
  For better understanding and use different facilities of Mule4 Error framework, we can use many expressions. And these expressions can be useful for logging and handling Mule 4 Errors.

  Field	Selector Expression	Description
  Description	#[error.description]	A description of the problem.
  Detailed Description	#[error.detailedDescription]	A description of the problem, which can be the same or more extensive than the description.
  Type	#[error.errorType]	A type, used to characterize the problem and allow for routing within an error handler.
  Cause	#[error.cause]	The underlying Java Throwable that resulted in the failure.
  Message	#[error.errorMessage]	An optional Mule message about the problem.
  Child Errors	#[error.childErrors]	An optional collection of inner errors, used by elements like Scatter-Gather to provide aggregated route errors.

As like in Java Exceptions hierarchy, Mule 4 come up with same patterns. The top most Error Type is ERRORS and its immediate Childs are ANY and CRITICAL

Mule Errors are divided in two segments separated by “:”. First part is namespace (Example: MULE, HTTP, FILE, DB) and second part is identifier (Example: SECURITY, CLIENT_SECURITY, UNAUTHORIZED, NOT_FOUND, CONNECTIVITY).

The namespace are unique and identifier can be duplicate, it means namespace are define based on domain (Ex: HTTP, FILE) and for each domain functionality can be same (Ex : NOT_FOUND). So, when define our custom Error type we have keep this in consideration.

Another important characteristic of error types is that they might have a parent type. For example, HTTP:UNAUTHORIZED has MULE:CLIENT_SECURITY as the parent, which, in turn, has MULE:SECURITY as the parent. This will help us to refer Global error handling and that will help us define Custom Error Types within our organisation.

The hierarchies means the routing can be more general, means MULE:SECURITY can catch HTTP:UNAUTHORIZED or Oauth Errors.

All errors are either ANY or CRITICAL. It’s important to note the UNKNOWN type, which is used when no clear reason for the failure is found. UNKNOWN is also can handle through ANY type.

In terms of Connectors, its defines its error type hierarchy considering the core runtime one. So, it is advised that when we create custom connectors we have to define the error type with respect to core runtime. CONNECTIVITY and RETRY_EXHAUSTED are the common types we have to define when we create custom connectors.

• What is Scope?
  • A Scope is a type of component that groups together a sequence of event processors to apply some programming behaviour to that isolated sequence of event processors.
  • When we add a scope in a flow, the default behaviour of the flow will change. So, before applying any scope into a flow we have to know what that applied scope can change in flow behaviour.


• What is try block in Java?
  • People came from Java background will know about “try block”. Java try block is used to enclose the code that might throw an exception. It must be used within the method.
  • If an exception occurs at the particular statement of try block, the rest of the block code will not execute. So, it is recommended not to keeping the code in try block that will not throw an exception.


• What is Try Scope?
  • The Try scope enable us to handle errors that may occur when we try execute any mule component.
  • A Try scope can handle one or more operations, then catches and handles any exceptions that might be thrown by any of these enclosed operations.


• Error Handling using Try Scope
  When design a flow, we should try to group the operation together that are likely to experience errors inside a Try scope.
  Best practice to configure the operations inside the Try scope to be processed as a transaction.
  
  
  Once the error raised by a component inside a Try scope, then the Try scope’s error handler is execute and act accordingly:

  • On Error Continue
    Executes and sends the result of the execution to its container Try scope, which uses that result to complete the execution successfully. Any transactions at this point are also committed.
  
  
  • On Error Propagate
    Rolls back any transactions, then executes and uses that result to re-throw the existing error, causing its container Try scope’s execution to fail.

There are two types of errors in Mule 4:

•   System errors :-
  System errors are errors that occur outside of Mule flows when no Mule events are involved.
  These are usually issues with deployment startup or mal-formed code or when a connection to an external system fails.
  System error handlers are can't be configurable in Mule.


•   Messaging errors :-
  Messaging errors that happen within a flow when there is some kind of processing issue.
  These types of errors create Error Objects which (in most cases) can be handled.
  We can handle Mule messaging errors in more than one way:

  • Using On Error components inside flow’s Error Handler component
  • Using Error Handler component in outside of a flow(create global Error Handler) and reference it from other Error handler configuration.
  • We can use Try Scope to handle messaging errors. The Try Scope has built-in Error Handler in which we can configure On-Error components.
  • If we don’t want to use any error handling components in our flows, Default Error Handling can help us to handle errors.

This is a default features of Mule 4 to handle errors if use don’t handle errors using Error handling components.

By default, unhandled messaging errors are logged and propagated to caller. 

By default, when a flow raise an error, the normal execution of the flow stops, and the process transfers to the flow’s default error handler, which propagates the error to caller.

Once an error raise in Mule flow, error handler route the error to On-Error component. It could be “On Error Continue” or “On Error Propagate”.

• On Error Continue


• On Error Propagate

When a series of steps in a flow must succeed or fail as one unit, Mule uses a transaction to demarcate that unit. The same way, use TRY scope, so that set of operations considered as a single unit, which will either succeed or fails.

A transaction is a series of actions that should never be partially executed. 

The Try scope treats child operations as a transaction when the Transactional Action (transactionalAction) is set to ALWAYS_BEGIN or BEGIN_OR_JOIN. 

Transactions can be configured in TRY scope like this :-

• INDIFFERENT :-
This is default. If a transaction is active, the scope joins it. If not, the scope does not create a transaction.


• BEGIN_OR_JOIN :-
It depends upon the caller component. If current flow processing has already started a transaction by caller previous component/flow, the scope joins it. If not, the scope initiates a new transaction.


• ALWAYS_BEGIN :-
It always started a new transaction every time the scope is executed.

If you like the blog on "Error Handling in Mule 4", please follow with me in next topic to understand about "Coming soon".