[bv-dev] When is a method validated

[Rich Midwinter]

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 at 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 at hibernate.org>:
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20120227/78096b28/attachment-0001.html