• Error Handling Reuse
  • Error Handling Reuse Documentation
• Error Handling Use Cases
  • Catch Exception Strategy Behavior
    • Catch Exception Strategy Documentation
  • Choice Exception Strategy Behavior
    • Choice Exception Strategy Documentation
    • Expression Evaluator Improvement Documentation
      • Exception Type Expression Evaluator Documentation
      • Expression Configuration Reference
  • Rollback Exception Strategy Behavior
    • Rollback Exception Strategy Documentation
• Exception-Transaction Architecture Clean Up
• Outlines for Error Handling Doc Page Cluster

Overview and Strategy

Why improve Error Handling in Mule 3.3?

Even though error handling has undergone a fair amount of work since Mule 2 there are still significant quality and usability issues that need to be addressed.

Usability

• Simple use cases (catch) cannot be implemented out of the box and require custom code.
• Most common use cases are difficult to implement using <default-exception-strategy>
• Complex to define custom behavior
• Poor documentation
  • Documentation does not explain basic things as which is the content of the Message being routed through exception strategy, what happen with the result of exception strategy functionality, how to implement a custom exception strategy, etc
• Complex to implement custom exception strategy

Quality

• Lot of bugs have been reported, even with Mule 3.1/3.2.
• Error handling and transaction management is hard to test and lack tests.
• TransactionTemplate/ExceptionStrategy co-ordination broken in Mule 3.2.
• There are some inconsistencies between transports.

Error-Handling improvement stories

1) Improve Quality

• Error handling code is error prone due to the fact that is not centralized. Each component has custom code to manage exception which makes error handling error prone and not consistent. Error handling architecture clean-up will provide a centralized way to handle exception and make mule consistent.

MULE-5911 - Architecture clean-up wiki

2) Improve Documentation

• Create missing documentation for Mule 3.1.x and Mule 3.2.x. Certify it by written functional test cases. Write blogs first to improve visibility.
• For each new feature documentation and blogs are part of the story acceptance criteria. Testing will certify that provided functionality does what acceptance criteria describes and that documentation describes the same behavior as acceptance criteria

MULE-5899 - Blogs: Getting the most out of mule error handling - Mule Error Handling: Most Common Use Cases part 1 - Mule Error Handling: Most Common Use Cases part 2

3) Provide missing functionality, Simplify existing functionality.

Leave <default-exception-strategy> as it is

Implement new exception strategy element/s that simplifies configuration for most common use cases

4) Facilitate creation of custom exception strategies

• Implement TemplateMethod in order to simplify custom exception strategies implementation

*5) Improve Error Example

Strategy

---- 3.3 M1 ---

• 1) Documentation first (MULE-5899 FixVersion: M1)
  • Improve existing Mule 3 documentation first since it has a great immediate impact in usability for Mule 3.1 and 3.2 users and it's low in effort.
  • Also provides functional test coverage before implementation work.
• 2) Improve TransactionTemplate/ExceptionHandling architecture/(MULE-5911 FixVersion: M1)
  • Significantly increase testability and unit tests before implementation work.
  • Done in advance since it will affect every new feature
  • Facilitates development of new features
• 3) Implement most need use case: "Catch and return result of error processing"

---- 3.3 M1 ---
---- 3.3 M2 -> ---

• 4) Implement/simplify other use cases
  • Work with support and services to get feedback about most needed functionality
  • Define use cases
  • Prioritize use cases
  • Create prototypes for each use case to get feedback
  • Implement them
  • Review them (Demo friday)

For each story: create a wiki page about it with documentation about proposed solution and try to get feedback from community and mule employees.

More Detail

Mule 3.3 stories:

Milestone 1

Backlog

To be added

Create a centralized way to manage SystemExceptionHandling calls during flow execution. (Includes documentation about which exception are managed by MessagingExceptionHandling and which ones are managed by SystemExceptionHandling).
As a Mule developer I want to be able to define a custom exception strategy to customize some aspects of exception handling in a clean way. (Includes documentation about how to do it)

Detailed error handling problems

Documentation is poor, it doesn't explain:

• Which exception are going to be managed by MessagingExceptionHandler and which are going to be managed by SystemExceptionHandler.
• How a message is transformed before being routed to MessagingExceptionHandler.
• What happen with responses when a flow has MEP request-response and an exception is thrown.
• How to implement a custom exception strategy.
• How <default-exception-strategy> can be configured.
• What is the rule for commit/rollback a transaction.
• When transactions are resolved.
• When XA transactions are suspended/resumed.

Lot of bugs in Mule 3.1.x and 3.2.x:

• MULE-5808: Mule not invoking exception strategy when an exception is thrown in asynchronous flow
• MULE-5739: When configuring <default-exception-strategy> exception message is no longer routes to nested processor/endpoint unless configured to commit
• MULE-5738: When configuring <default-exception-strategy> inbound transaction is committed by default when no commit or rollback pattern is configured
• MULE-5801: custom exception handling don't work in http inbound
• MULE-5737: Flows does not handle exception when invoked via i) request-response vm inbound endpoint ii) flow-ref
• EE-2336: Exception-based Router Doesn't Work (Always RollsBack) XA Transactions
• EE-2340: Transaction contexts are not propagated to exception strategies
• EE-2389: Jms transaction is being commit after an exception in a component
• EE-2505: Transaction contexts are not propagated to exception strategies when the exception is thrown by the outbound-endpoint
• EE-2511: Transactions are resolved when they shouldn't. Response processor are not considerer
• EE-2534: Exception Strategy does not allow to modify payload (or invoke the response block)
  continues...

Functionality provided is not what users need

• Users want to route message that was being processed before exception through exception strategy.
• Users want to route original message before being processed through exception strategy.
• Users want to route message based on exception type or content type.
• Users want to stop flow execution based on exception type.
• Users want to return the result of routing the message through exception strategy when inbound endpoint MEP is request-response.
• Users want to be able to reuse exception strategies or have a default one.

Complex to define custom behavior

• AbstractMessagingExceptionStrategy in 3.1.x works as a Template method. So users can extend from it an override specific methods to change it's behavior. That was broken in 3.2.x and the way to create custom exception strategies is not straightforward.