We’ve been using entity listeners to perform some validation. We fail a validation attempt by throwing a custom RuntimeException called ValidationException. Now we need to add some custom functionality when validation fails. My choice to do so was just add a handler for ValidationException, called ValidationExceptionHandler.
Stepping through the code when AbstractGenericExceptionHandler is checking if ValidationExceptionHandler contains the thrown exception in it’s classNames field, I notice it is not checking for ValidationException like I would expect, but instead is checking for ServerRpcManager.RpcInvocationException.
I have reproduced this with built-in RuntimeExceptions so I know the issue (assuming this isn’t designed behavior) isn’t with the custom exception, and I know ValidationException is available to both client and middleware tiers.
I guess this boils down to two questions:
Would working around this by just handling ServerRpcManager.RpcInvocationException in place of my ValidationException cause any obvious issues with CUBA functionality?
And is this the proper way to handle complex validation? The validation in question requires checking other states in the application and can’t be handled by annotations on entity fields. It must also be run whenever the entity is updated (which was the inspiration for moving validation from the screen to the listener), so just validating fields on an edit screen is a no-go as well.