Introduction
This week, I conducted a poll asking which error handling pattern Mendix developers implement most frequently. The results were revealing:
Poll Result
These results confirm what many experienced Mendix architects already know: there’s no one-size-fits-all approach to error handling. Each pattern serves a distinct purpose, and knowing when to use each is the hallmark of mature application architecture.
In this article, I’ll share proven implementation patterns for each error handling approach, demonstrating how proper error handling can elevate your Mendix applications from functional to enterprise-grade.
The Cost of Inadequate Error Handling
Before diving into implementation strategies, let’s acknowledge the consequences of poor error handling. We’ve all seen it – the dreaded generic error message:
“An error occurred. Please contact your system administrator.”
This message indicates the application encountered an exception it wasn’t designed to handle gracefully. It creates three significant problems:
- User Experience Degradation: Users receive cryptic messages instead of actionable information
- Troubleshooting Complexity: Support teams must dig through logs to understand what happened
- Data Integrity Risk: Incomplete transactions may leave the system in an inconsistent state
Implementing proper error handling isn’t just a technical best practice – it’s a business imperative that directly impacts user satisfaction and operational efficiency.
Strategic Error Handling: The Three Core Patterns
1. Custom With Rollback
When to use it: Database operations where transactional integrity is critical
This approach is ideal when multiple database operations must succeed as a unit. It ensures that if an error occurs, all database changes within the current transaction are reverted to maintain data consistency.
Key implementation considerations:
- All database changes within the transaction will be rolled back to the last save point
- The error handler can still capture detailed error information for logging
- Works consistently across microflows and sub-microflows within the same transaction
- Creates a clean state for potential retry logic
Example: Order Processing System
In an order processing system, database consistency is paramount. Consider this implementation pattern:
Example: Order submission with inventory updates that uses Custom with Rollback
In this example, the main microflow calls the SUB_SubmitOrder sub-microflow with “Custom with rollback” error handling. When an error occurs:
- The error is caught and logged with detailed context
- A user-friendly error message is displayed
- All database changes (order creation, inventory updates) are rolled back
- The transaction ends in a clean state
This pattern is essential when handling financial transactions, inventory management, or any process where partial completion could create data integrity issues.
2. Custom Without Rollback
When to use it: External system integrations where database state should be preserved
This approach is ideal for operations that involve external system calls that shouldn’t affect the database state of your Mendix application. It allows operations completed before the error to remain committed while providing control over subsequent actions.
Key implementation considerations:
- Database changes made before the error point ARE committed
- Subsequent operations are skipped
- Perfect for implementing retry logic for external API calls
- Requires manual consistency management
- Enables custom cleanup or compensation logic
Example: Order Email Notification
When sending order confirmation emails, you typically want to preserve the order details even if the email delivery fails:
Example: Email notification that uses Custom without Rollback
In this implementation:
- The order data is committed to the database
- The system attempts to send an email notification
- If the email fails, the error is logged but doesn’t affect the order data
- The flow continues to subsequent steps (like order logging)
This pattern is optimal for external service integrations, notification systems, or any scenario where partial success is better than complete rollback.
3. Continue on Error
When to use it: Batch operations where individual failures shouldn’t halt the entire process
This approach allows processing to continue despite errors in non-critical operations. It’s particularly valuable in batch processing scenarios where some failures are expected and acceptable.
Key implementation considerations:
- Most permissive error handling option
- Execution continues to the next activity even if an error occurs
- Ideal for operations within loops
- Requires careful consideration of data consistency implications
Example: Logging Order Information
When logging order information for analytics purposes, a failure shouldn’t affect critical business processes:
Example: Logging with Continue option
In this implementation:
- The system attempts to log order information for analytics
- If logging fails, the flow continues without interruption
- No error message is displayed to the user
- The main business process completes successfully
This pattern is ideal for non-critical operations like logging, analytics tracking, or batch processing where individual failures can be tolerated.
Advanced Implementation Techniques
Error Context Management
Enterprise-grade error handling goes beyond selecting the right pattern – it requires capturing meaningful context that facilitates troubleshooting. Implement these techniques:
Structured Error Objects (Optional): Create a dedicated entity to store error information including:
- Error code/type
- Timestamp
- User context
- Operation being performed
- Relevant business object identifiers
- Technical error details (for logs only)
External Logging Integration:
- Route logs to systems like Splunk, Datadog, or New Relic for analysis
- Consider a hybrid approach where INFO and WARNING logs are written only to external systems
- Store ERROR and CRITICAL logs in both the database and external systems
- Use asynchronous logging patterns to minimize performance impact
- Consider log volume when designing your logging strategy to prevent performance degradation
Centralized Logging Microflows:
- LOG_UserAction – For tracking user-initiated operations
- LOG_SystemEvent – For system-level events and operations
- LOG_IntegrationEvent – For external system interactions
- LOG_SecurityEvent – For authentication and authorization events
Managing Nested Transactions
One of the most challenging aspects of error handling in Mendix is managing error propagation across nested microflows. Consider this pattern:
Pattern: Mixed Error Handling with Nested Microflows
When a microflow calls a sub-microflow, the error handling approaches can interact in complex ways:
- Main microflow (Custom with rollback) → Sub-microflow (Custom with rollback): Sub-microflow errors are handled within the sub-microflow If an error event is triggered in the sub-microflow, the main microflow’s error handler is executed All changes in both microflows are rolled back
- Main microflow (Custom with rollback) → Sub-microflow (Custom without rollback): Changes in the sub-microflow are committed even if the main microflow rolls back This creates a partial commit scenario that must be carefully managed
- Main microflow (Custom without rollback) → Sub-microflow (Custom with rollback): Changes in the sub-microflow will be rolled back on error Changes in the main microflow before the sub-microflow call remain committed
The complexity of nested transactions goes a level further with the decisions to end sub-microflow ending in Error or End events.
Understanding these interactions is crucial for architecting complex transaction patterns in enterprise applications.
Architectural Best Practices
Based on my experience implementing Mendix solutions across industries, here are key architectural patterns for error handling:
1. Error Handling Layer
Create a dedicated error handling module with:
- Standardized error entities and enumeration types
- Reusable error handling microflows
- Consistent user feedback mechanisms
- Centralized logging infrastructure
- Error notification framework
2. Transaction Management Strategy
Design your application with explicit transaction boundaries:
- Keep critical operations within a single transaction using Custom with Rollback
- Use sub-transactions via Custom without Rollback for operations that should persist regardless of parent transaction
- Implement compensation logic for rollback scenarios that span multiple systems
3. User Experience Design for Errors
Develop a comprehensive error presentation strategy:
- Create user-friendly error messages that provide actionable information
- Implement different visualization for different error types (validation, system, external)
- Provide appropriate recovery paths based on error context
- Consider multi-lingual error message support for international applications
- Consider giving an action like send email to support with error details
4. Error Monitoring and Analytics
Implement infrastructure for error tracking and analysis:
- Aggregate error logs for pattern detection
- Create dashboards for error frequency and impact analysis
- Establish alerting for critical error thresholds
- Implement error-driven continuous improvement processes
Common Misconceptions
Based on my experience and discussions with developers and clients, here are some common misconceptions about error handling in Mendix:
Misconception 1: “Error handling is only needed for exceptional cases”
Reality: Robust error handling should be considered for every microflow. Even operations that appear straightforward can fail due to concurrency issues, constraints, or unexpected data scenarios. Treating error handling as a fundamental architectural concern rather than an exception path is essential for enterprise applications.
Misconception 2: “One error handling approach is sufficient for my entire application”
Reality: As our poll results showed, different scenarios require different approaches. Using only Custom with Rollback everywhere can lead to unnecessary transaction overhead, while overusing Continue on Error can create data consistency issues. A mature application architecture applies each pattern strategically based on operation context.
Misconception 3: “You can’t modify the generic error message action”
Reality: While you can only modify the default “An error occurred…” message text, you can prevent it from appearing by implementing proper error handling throughout your application. With comprehensive error handling, users should never see this message.
Misconception 4: “Error handling slows down development”
Reality: While implementing proper error handling requires initial investment, it dramatically reduces troubleshooting time and improves application quality. Mature organizations typically develop reusable error handling patterns that can be efficiently applied across projects.
Conclusion
Error handling is not merely a technical requirement but a strategic architectural decision that directly impacts user experience, data integrity, and operational efficiency.
The choice between Custom with Rollback, Custom without Rollback, and Continue on Error should be driven by the specific requirements of each operation.
As our poll results showed, experienced Mendix developers use a mix of approaches based on context. Your error handling strategy reveals your application’s maturity level – moving from reactive error handling to a proactive, architectural approach represents an evolution in development sophistication.
For organizations looking to elevate their Mendix implementation with enterprise-grade error handling patterns, Golden Earth provides specialized consulting services for Mendix architecture and implementation. Our team of senior Mendix developers can help you design and implement robust error handling strategies tailored to your specific business requirements.