Hi<div><br></div><div>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.</div>
<div><br></div><div>Rich</div><div><br><br><div class="gmail_quote">On 27 February 2012 08:52, Hardy Ferentschik <span dir="ltr"><<a href="mailto:hardy@hibernate.org">hardy@hibernate.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I think there are really two view points in this case.<br>
<br>
1. method centric (Emmanuel's suggestion)<br>
The parameters are validated at the moment they are passed to the method (after all interceptors did their work) and the return value<br>
gets validated as returned by the method. This could lead to the fact that, if there are interceptors which modify the return value before<br>
passing it back to the client, return value constraints could be broken (e.g. return null for a non null value)<br>
<br>
2. client centric (Gunnar's suggestion)<br>
The parameter validation is again last in the interceptor chain. In this case, however, the return value would be validated after the interceptors<br>
are run. The benefit is that return value constraints gets validated just before they are returned to the client.<br>
<br>
>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<br>
directly returned by it. There should be no consideration for interceptors.<br>
<br>
#2 seems to make more sense from a client perspective, but really which interceptor would modify a return value? Interceptors are good for many<br>
things, but I definitely would not expect them to change the return value (at most to throw an exception).<br>
<br>
For that reason and the fact that #1 is symmetric I vote for #1<br>
<span class="HOEnZb"><font color="#888888"><br>
--Hardy<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Feb 27, 2012, at 8:31 AM, Gunnar Morling wrote:<br>
<br>
> Hi,<br>
><br>
> I agree with respect to parameter validation.<br>
><br>
> 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.<br>
><br>
> The order would then look like that:<br>
><br>
> ...<br>
> validate parameters<br>
> method call<br>
> ...<br>
> validate return value<br>
><br>
> --Gunnar<br>
><br>
> Am <a href="tel:26.02.2012%2019" value="+12602201219">26.02.2012 19</a>:28 schrieb "Emmanuel Bernard" <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>>:<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</div></div></blockquote></div><br></div>