Hi
I'd lean towards #1 too, for broadly the same reasons Hardy states. Freeing
the method author from even having to consider the effect of interceptors
seems like a "good thing" to me.
Rich
On 27 February 2012 08:52, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
Hi,
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
directly 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
--Hardy
On Feb 27, 2012, at 8:31 AM, Gunnar Morling wrote:
> Hi,
>
> 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 parameters
> method call
> ...
> validate return value
>
> --Gunnar
>
> Am 26.02.2012 19:28 schrieb "Emmanuel Bernard"
<emmanuel(a)hibernate.org>:
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev