- the lack of symmetry is fishy: granted that's not an argument and our inheritance is not either in that regard

- if the inner method returns an unexpected result, interceptors / decorators might stumble upon it

- an unexpected result should probably rollback the transaction just like an unexpected parameter does

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.

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 modifications as an edge-ish case.

On 27 févr. 2012, at 08:31, 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@hibernate.org>:
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev