New convenience methods on Validator: void assertValid(Object o)/assertValidProperty(...)/assertValidValue(...) which throw a runtime ValidationException
90% of the time we want to do:
So why not supply a facade method to make it easy for us developers (especially those migrating from hibernate validator 3)?
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.
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.
That one slipped off 1.1 but could we experiment in Hibernate Validator first? This could even be static helper methods.
Now that we have method validation, what are the use cases that require that kind of pattern in an application code? (Integrator can have it the hard way).
This is a very old issue, from a previous project & company. The context was a swing fat client that connected to a JEE server backend. Both the client and the server did the validation (the client to show it to the user, the server for security reasons).
I haven't kept up with the latest validator improvements, so this issue might be stale. Feel free to dismiss it.
One intresting concern was that if the backend throw their own custom BackendInvalidationException, that the frontend experienced an unmarshalling error trying to deserialize that BackendInvalidationException instance. That effectively ate the real error message. Therefore, it made sense that both the frontend and backend used the same Exception class for invalidation errors - and it was in the shared classpath.