Offer helper classes to build ConstraintViolationExceptions (and potentially raise them)

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:

From http://docs.jboss.org/hibernate/stable/validator/reference/en/html_single/#validator-usingvalidator-validate

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.

Environment

None

Activity

Show:
Gunnar Morling
September 26, 2011, 11:18 PM

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.

Emmanuel Bernard
February 17, 2013, 7:30 PM

That one slipped off 1.1 but could we experiment in Hibernate Validator first? This could even be static helper methods.

Emmanuel Bernard
October 30, 2014, 11:16 AM

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).

Geoffrey De Smet
October 30, 2014, 11:24 AM

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.

Geoffrey De Smet
October 30, 2014, 11:27 AM
Edited

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.

Assignee

Unassigned

Reporter

Geoffrey De Smet

Labels

Feedback Requested

None

Feedback Requested By

None

backPortable

None

Suitable for new contributors

None

Pull Request

None

backportDecision

None

backportReEvaluate

None

Components

Fix versions

Affects versions

Priority

Minor
Configure