This document discusses how to handle exceptions in Mule applications. There are two types of exceptions: system exceptions which occur at the system level, and messaging exceptions which occur when messages are involved. By default, exceptions stop flow execution, log the exception, and roll back transactions. To continue execution, reconnection strategies can be used for system exceptions while messaging exception strategies specify custom exception handling. Messaging exception strategies contain catch, rollback, choice, reference, and custom handlers and can be defined globally for reuse in multiple flows.

1. Mule Exceptions

2. Handling Exceptions
Handling Exceptions:
o An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program.
o To continue the flow execution, we should handle the exceptions.
o There are 2 types of exceptions:
 System Exceptions:
 It is thrown at the system-level when no message is involved.
 It occurs during application start-up or when a connection to an external system fails.
 Message Exceptions:
 It is thrown within a flow whenever a message is involved.
 It occurs due to invalid data or unexpected application scenario.

3.  Handling System Exceptions:
o When a system exception occurs, a default system exception strategy is invoked.
o Default System Exception Strategy behavior:
 It handles all the system exceptions thrown in Mule applications.
 It stops execution of the flow, logs the exception & rolls back the transaction.
 It is non configurable.
o If the system exception is caused by a connection failure, then we should apply Reconnection Strategy
to continue the flow execution by retrying connection.
 Setting Reconnection Strategy:
Handling System Exceptions

4.  Handling Messaging Exceptions:
o When a messaging exception occurs, a default messaging exception strategy is invoked.
o Default Messaging Exception Strategy behavior:
 It implicitly and globally handles all messaging exceptions thrown in Mule applications.
 It stops execution of the flow, logs the exception & rolls back the transaction.
 It is non configurable.
o If a messaging exception is caused by invalid data or due to unexpected application scenario, then we
should apply our own Messaging Exception Strategy to continue the flow execution.
 Messaging Exception Strategy:
o When a message being processed through a Mule flow throws an exception:
 Normal flow execution stops.
 The message is passed to the first processor in the exception strategy.
Handing Messaging Exceptions

5. o Message Exception Strategies are added to the error handling section of a flow.
o Each Exception Strategy can contain any number of message processors.
o All flows can have their own exception strategies.
o Subflows cannot have their own exception strategies.
o If a flow does not have an exception strategy, the strategy of the calling flow is used.
o Each flow can contain only one Exception Strategy.
 Choice Exception Strategies can contain one or more catch and/or rollback exception strategies.
o Mule messaging exception strategies can be categorized in below main parts:
 Catch: Catches exceptions based on conditions.
 Rollback: Rolls back message for reprocessing.
 Choice: Selects one of multiple catch and/or rollback strategies based on condition.
 Reference: Allows us to reference globally defined strategies.
 Custom: Allows us to specify a custom class for handling the exception.
Defining Messaging Exception Strategy

6.  Flow:
 Response:
Defining Messaging Exception Strategy

7.  Defining Global Exception Strategy:
o We can reuse exception handling strategies by defining them outside a flow.
 We can drag them out and drop them outside any flow.
 Typically, we put them in our global configuration file.
o We use Reference Exception Strategy to give reference to global exception handlers.
o Default Exception Strategy can be replaced with our own Global Default Exception Strategy by
specifying in global.xml file.
Defining Global Exception Strategy