On 15 oct. 2010, at 10:55, Hardy Ferentschik wrote:
>
> Another thing we wondered about is the default behaviour of built-in
> constraints when they validate null values. Are they supposed to succeed
> on null values by default?
That's a suggestion by the Bean Validation Specification. The spec says:
"While not mandatory, it is considered a good practice to split the core
constraint
validation from the not null constraint validation (for example, an @Email
constraint will return
true on a null object, i.e. will not take care of the @NotNull validation)
null can have multiple meanings but is commonly used to express that a
value does not make sense, is not
available or is simply unknown. Those constraints on the value are
orthogonal in most cases to other constraints.
For example a String, if present, must be an email but can be null.
Separating both concerns is a
good practice."
I never liked the idea of having to treat null as a different kind of constraint. One of
the advantage of the approach taken by the spec is that it's easier to the user (at
the expense of the constraint implementor), will usually be less verbose and is simpler
for the spec that does not have to treat null as special.