<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I am open for discussion on this one. I have considered your approach but a couple of things made me shy away from it:<div><br></div><div>- the lack of symmetry is fishy: granted that's not an argument and our inheritance is not either in that regard</div><div>- if the inner method returns an unexpected result, interceptors / decorators might stumble upon it</div><div>- an unexpected result should probably rollback the transaction just like an unexpected parameter does</div><div><br></div><div>But in the end it boils down to this question: should we validate the inner method or should we validate the client calling? Depending on that the interceptor moves.</div><div><br></div><div>We cannot realistically ask for two interceptions, one first and one last. Also, the specs can't really protect people from doing really really bad things with interceptors so I see the param / return value &nbsp;modifications as an edge-ish case.</div><div><br><div><div>On 27 févr. 2012, at 08:31, Gunnar Morling wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p>Hi,</p><p>I agree with respect to parameter validation.</p><p>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.</p><p>The order would then look like that:</p><p>...<br>
validate parameters<br>
method call<br>
...<br>
validate return value</p><p>--Gunnar</p>
<div class="gmail_quote">Am 26.02.2012 19:28 schrieb "Emmanuel Bernard" &lt;<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>&gt;:<br type="attribution"></div>
_______________________________________________<br>beanvalidation-dev mailing list<br><a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/beanvalidation-dev<br></blockquote></div><br></div></body></html>