Bryan <[EMAIL PROTECTED]> writes: > However, hoping to make client code cleaner and to avoid setter > functions doing expensive db lookup validations, I do not validate > during the setter, but instead defer it until the client explicitly > asks for the validity of the business object. So the essence of the > client's request at that point is "what are the invalid values for the > object", and an exception should only be raised if there was something > stopping this request from being served. Invalid business object > field values do not stop the functionality of the invalid() method.
This is perfectly fine IMHO, in fact this is similar to how django does form validation. Each form has a property 'is_valid' and validation is only triggered when form.is_valid is checked. This doesn't raise exceptions but makes the errors available to the form user. -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list