I think there are really two view points in this case.
1. method centric (Emmanuel's suggestion)
The parameters are validated at the moment they are passed to the method (after all
interceptors did their work) and the return value
gets validated as returned by the method. This could lead to the fact that, if there are
interceptors which modify the return value before
passing it back to the client, return value constraints could be broken (e.g. return null
for a non null value)
2. client centric (Gunnar's suggestion)
The parameter validation is again last in the interceptor chain. In this case, however,
the return value would be validated after the interceptors
are run. The benefit is that return value constraints gets validated just before they are
returned to the client.
From a design by contract point of view I would expect the behavior of
#1. Method level validation is about what is passed to a method and
returned by it. There should be no consideration for interceptors.
#2 seems to make more sense from a client perspective, but really which interceptor would
modify a return value? Interceptors are good for many
things, but I definitely would not expect them to change the return value (at most to
throw an exception).
For that reason and the fact that #1 is symmetric I vote for #1
On Feb 27, 2012, at 8:31 AM, Gunnar Morling wrote:
I agree with respect to parameter validation.
But shouldn't the validation interceptor also run last for return value validation,
that is after all interceptors potentially modifying the return value? That way both
contracts (pre- and postconditions) are enforced as closest to their clients (method
implementation respectively method caller) as possible. Other interceptors generally
couldn't rely on the correctness of parameters/return values.
The order would then look like that:
validate return value
Am 26.02.2012 19:28 schrieb "Emmanuel Bernard" <emmanuel(a)hibernate.org>:
beanvalidation-dev mailing list