]
Gunnar Morling commented on BVAL-199:
-------------------------------------
I'm unsure about this. Personally I think the payload example shows that this is
better located in user code. Also the requirements about the resulting error messages
differ from situation to situation IMO.
New convenience methods on Validator: void assertValid(Object
o)/assertValidProperty(...)/assertValidValue(...) which throw a runtime
ValidationException
---------------------------------------------------------------------------------------------------------------------------------------------------------
Key: BVAL-199
URL:
http://opensource.atlassian.com/projects/hibernate/browse/BVAL-199
Project: Bean Validation
Issue Type: New Feature
Components: spec-general
Affects Versions: 1.0 final
Reporter: Geoffrey De Smet
90% of the time we want to do:
{code}
Set<ConstraintViolation<Car>> constraintViolations =
validator.validate(car);
if (constraintViolations.size() > 0) {
throw new MyValidationException(decentErrorMessage);
}
{code}
From
http://docs.jboss.org/hibernate/stable/validator/reference/en/html_single...
So why not supply a facade method to make it easy for us developers (especially those
migrating from hibernate validator 3)?
{code}
validator.assertValid(car);
{code}
That allows the bean validation to standarize the Exception too:
a ValidationException (or InvalidStateException or whatever you call it), which is of
course a runtime exception.
That in turn, allows the front-end frameworks to deal with that exception more cleanly
(give the user a clue why the business method failed when it imported that address without
a street from an import addresses file).
Give special care to the message of that exception. It should clearly state at least 1 of
the validations that failed (in english, not i18n)
so when we find such an exception in the log we can easily see what caused it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: