DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24369>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24369 Validator.validate() exception handling for ValidatorException ------- Additional Comments From [EMAIL PROTECTED] 2003-11-10 18:08 ------- I include below a portion of Janet Moyer's message which I consider essential for this discussion. The core of the issue is not the masking of ValidatorExceptions raised by the validation framework, but whether or not ValidatorExceptions ought to be raised by the validation rule implementations themselves. Janet's requirements is that some means of notification regarding system level errors (not invalid data - currently handled in a usable fashion by the framework - but inability to validate the data - currently masked as equivalent to invalid data) is required. A reasonable means of doing this seems to be for validation rule implementations to throw ValidatorException. However, because the rule methods are invoked using reflection, these exceptions are wrapped into InvocationTargetException. The framework currently makes no effort to unwrap these exceptions and examine them to determine whether or not they are ValidatorExceptions. (The catch clause David points out should do this, if it is to be done.) Assuming this is appropriate behaviour, I'll attach a patch shortly. -----Original Message----- From: Moyer, Janet [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2003 9:05 AM To: '[EMAIL PROTECTED]' Subject: Commons Validator Limitation <SNIP /> The problem we have is in how the Validator handles exceptions. Our rules access databases and backend systems for data needed during validation. If a system problem occurs, such as a database is down, our rules try to throw a ValidatorException. Since the plugin methods are invoked by reflection, our exceptions are wrapped in InvocationTargetExceptions. Validator.validate() treats this as a validator error rather than a ValidatorException. This means all our system exceptions are treated the same as data problems. For example, we have a rule that validates a duplicate add of a customer account. The validation plugin reads a database to check whether the account exists. The problem is that if the database is down, the Validator.validate() masks the exception, and tells us that the account already exists. <SNIP /> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
