Error Handling in Mule 4
Messaging error occurs when an event is processed through mule flow that throws an error-Normal execution stops and an event is passed through the first processor in the error handler.
If there is no error handler defined, a default error handler is used. Execution failures are represented with Mule errors that have the following components:
● A description of the problem.
● A type that is used to characterize the problem.
● A cause, the underlying Java Throwable that resulted in the failure
There are broadly two ways to define the errors in Mulesoft as below.
● Message Level Errors – Message level error occurs when mule message is involved. e.g. error occurred when calling a database or error occurred (http 401 unauthorized or 503 service unavailable etc.) while calling an external API
● System Level Error – System level error occurs when there is no mule message involved. E.g. connectivity issue to a JMS provider, connectivity issue to a Database. You cannot handle system level errors.
Error Object:
When an error is thrown, it creates an error object named as follows — Namespace (eg. HTTP) and Identifier (eg. BAD_REQUEST)
Example. HTTP: BAD_REQUEST, WSC: CONNECTIVITY, VALIDATION: INVALID_BOOLEAN
Each error object has 5 Components:
Error Type hierarchy reference:
Message Exception:
The message exceptions can now be handled at 3 different levels: If there is no error handling written at any of the levels, the Mule Default Error Handler is used, which stops the execution of the flow and logs the exception.
The Mule Default Error Handler is not configurable but can be replaced by our own Global error handler by creating a Configuration global element.
1. Application level-The handlers written at the application level are global handlers, which can be used to handle the errors thrown by any flow, which doesn't have its own error handling. Defining a default error handler for an application:
Add an error handler in the global configuration file
Flow level: The errors that are handled in the flow of the application.Flow level handlers can be added to regular Flows and private flows, but not to Subflows.
Processor Level: The errors that are handled at the processor level.To handle the errors at the processor level, add one or more processors into a Try Scope and handle it using the On Error Propagate or On Error Continue Scopes.
Error Handler Scopes:
On-Error Continue
On-Error Propagate
Try Catch Scope
Raise Error
On-Error Continue :
On-Error Continue catches the error and does not report it as an error, thus the processing of the flow continues even after the error has occurred. This error handler can be used in flows where you don’t want to stop the flow processing even if an error has occurred.
All processors in error handling scope are executed
● At the end of the scope − The rest of the scope that threw the error is not executed − The event is passed to the next level as if the flow execution has completed successfully
● The HTTP listener returns a successful response
On-Error Propagate:
In case of any errors, On-Error Propagate processes the error message and re-throws the error to its parent flow. No further processing is done on that particular flow. Error propagate scope handled as below:
● All processors in error handling scope are executed
● At the end of the scope
− The rest of the scope that threw the error is not executed
− The error is rethrown up to the next level and handled there
● The HTTP listener returns an error response.
Try-Catch Scope
Try-catch scope can be used within a flow to do error handling of just inner components. Try-catch scope can be very useful in cases where we want to add a separate error processing strategy for various components in the flow.
Custom error type:
This core component generates a Mule error, as if a failure had occurred, which allows you to customize its description and type.
RAISE CORE RUNTIME ERROR TYPES For core runtime error types, you must use the implicit namespace and identifier, you can only customize the error’s description message. For example: <raise-error type=“MULE:CONNECTIVITY” description=“Error description message”/>
RAISE CUSTOM ERROR TYPES For custom error types, declare a new namespace. The namespace of an error type should help you identify the origin of an error. For example: <raise-error type=“ORDER:INVALID_DATA” description=“Email is invalid. Cannot complete transaction”/>
