Description:
Currently, there is a need for a consistent and flexible way to represent validation errors across the application, especially when dealing with custom business logic exceptions. We need a pluggable architecture that allows developers to catch these domain-specific exceptions and gracefully convert them into standard validation responses.
This feature introduces a contract to map exceptions (like those thrown during bean validation or custom business rules) directly to a ValidationResult.
Proposed Solution
We will introduce two core components to handle this routing and mapping:
-
ValidationExceptionMapper: A functional interface that defines the contract for interpreting an exception and translating it into a ValidationResult. Implementers will use this to encapsulate specific error messages, status codes, and the specific fields that failed validation.
-
ValidationExceptionChain: A mechanism to combine multiple ValidationExceptionMapper implementations into a single, sequential chain. This is an internal component.
How it Works
When an exception occurs, the ValidationExceptionChain processes it by iterating through all registered mappers.
- The chain delegates the exception to each mapper, and the first non-null ValidationResult produced is immediately returned.
- If none of the mappers can handle the exception, the system checks the suggestedCode.
- If the suggestedCode is 500 or greater, the exception is simply propagated upwards.
- If the suggestedCode is less than 500 (indicating a client error), a default ValidationResult is automatically generated to indicate a global validation failure.
Usage & Plugin Registration
Users can easily plug in their own custom mappers to handle specific business logic exceptions. These objects can be chained in the registry like so:
registry.listOf(ValidationExceptionMapper.class).add(new MyValidationErrorMapper());
To ensure this works seamlessly with popular validation libraries from the start, both HibernateValidatorModule and AvajeValidatorModule will provide built-in implementations to convert their respective exceptions into a ValidationResult properly.
Description:
Currently, there is a need for a consistent and flexible way to represent validation errors across the application, especially when dealing with custom business logic exceptions. We need a pluggable architecture that allows developers to catch these domain-specific exceptions and gracefully convert them into standard validation responses.
This feature introduces a contract to map exceptions (like those thrown during bean validation or custom business rules) directly to a ValidationResult.
Proposed Solution
We will introduce two core components to handle this routing and mapping:
ValidationExceptionMapper: A functional interface that defines the contract for interpreting an exception and translating it into a ValidationResult. Implementers will use this to encapsulate specific error messages, status codes, and the specific fields that failed validation.
ValidationExceptionChain: A mechanism to combine multiple ValidationExceptionMapper implementations into a single, sequential chain. This is an internal component.
How it Works
When an exception occurs, the ValidationExceptionChain processes it by iterating through all registered mappers.
Usage & Plugin Registration
Users can easily plug in their own custom mappers to handle specific business logic exceptions. These objects can be chained in the registry like so:
To ensure this works seamlessly with popular validation libraries from the start, both HibernateValidatorModule and AvajeValidatorModule will provide built-in implementations to convert their respective exceptions into a ValidationResult properly.