On 3 Dec, 09:48, "Dan Kubb (dkubb)" <[EMAIL PROTECTED]> wrote:
> my thoughts can be nicely summed up by the following:http://is.gd/a0QH
I agree that exceptions should only be raised in unexpected
situations. However, I also think that a validation error qualifies as
unexpected in this case. Here's why:
When calling a method named `save' I intuitively expect it to save the
object. Failure to do so is unexpected, and therefore merits an
exception. A method which implements the current behavior might be
better named save_if_valid.
So shouldn't (web) applications expect invalid data? Well yes, they
often should, but that doesn't necessarily mean that their ORM should.
In my opinion, it is wrong to call save (or create) on something that
cannot be saved. A programmer expecting invalid input is therefore
responsible for validating it before attempting a save, while one who
assumes that all data is valid should be free to call save directly
(and still be notified by an exception if things go wrong).
When invalid input is expected saves could be handled like this:
if object.valid?
object.save
else
# ...
end
This is how you would do it when not expecting invalid input:
object.save # Currently risky because of silent validation errors
Having said that, I do understand that it may be unpractical to change
the behavior of such a central part of the DataMapper API at this
stage. This has been an interesting discussion to follow nonetheless.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"DataMapper" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/datamapper?hl=en
-~----------~----~----~----~------~----~------~--~---
