Add cause exception to ValidationException - so that error handlers can get the validator implementation specific original constraint violations

[rbygrave]

I've just hooked up the validation to avaje-nima and looking at the difference between the avaje-validation ConstraintViolationException and avaje-http ValidationException.

When mapping from ConstraintViolationException -> avaje-http ValidationException we can lose details that ConstraintViolationException has and to me that could be problematic (and problematic for other validators that someone might wish to use).

I'm pondering if we should effectively remove / deprecate / not use the avaje-http ValidationException and instead allow the ConstraintViolationException to be thrown and then the error handler has full control over how the ConstraintViolationException is handled.

That is, the API requirement for avaje-http validate() becomes that it throws some RuntimeException (a ConstraintViolationException) and it's up to the http routing to have a error handler registered to handle that specific exception.

Another alternative is for ValidationException to have a cause which in the avaje-validation case is the ConstraintViolationException.

[SentryMan]

I like the consistency and plug and play between the different validators, maybe just add cause to Validation Exception?

[rbygrave]

maybe just add cause to Validation Exception?

Let's go with that and see how it plays out in 2.0-RC. My gut also likes the consistency and plug and play between the different validators. If/when an error handler needs the underlying cause exception it can be accessed so that should be good enough and simple/elegant enough.