Can you give me more direction on this point? You said people might rely
on this functionality, but while that may be true, it's also highly
unlikely anyone is because a log error entry was always emitted. To
allow the validation to then succeed opens up an unpredictable situation
for the application developer, which I think would be very worrisome. If
data must always be valid, then failing to access that data cannot be
considered a success.
This error condition should not be confused with a null or empty
property. This is asking to validate a field that doesn't exist. I do
not take this situation or change lightly, and IMO is a hole necessary
for patching. If you weren't logging an error already in Commons
Validator, there would be no disagreement from me; but because it is
clearly an error condition, it's an error that must also stop the use case.
Paul
Paul Benedict wrote:
Good point.
Niall Pemberton wrote:
STR-2611 just requested more info in the logged error message - but
this change goes further because in all cases except the required
validator validation will now fail if an exception is throw accessing
the property's value - whereas before it just skipped validation. For
anyone that has relied on that behaviour then its going to break their
application.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
