[ http://opensource.atlassian.com/projects/hibernate/browse/BVAL-199?page=c... ] Peter Davis commented on BVAL-199: ---------------------------------- It would be nice if such a feature could ignore "Warning" or severity payloads. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/BVAL-199?page=c... ] Emmanuel Bernard updated BVAL-199: ---------------------------------- Description: New convenience methods on Validator: void assertValid(Object o)/assertValidProperty(...)/assertValidValue(...) which throw a runtime ValidationException 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} 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. was: 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} 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: http://www.atlassian.com/software/jira