On Nov 29, 2008, at 1:09 PM, Alex Neth wrote:
>> The hook I mentioned should do it. Assuming that validation failures
>> are the only cause, then hook it with an :after, and check the errors
>> length.
>>
>> That way, if you still get a save failure, you can exception it if
>> you
>> want a little extra guarantee and it'll bubble up:
>>
>> Foo.hook(:save) { |foo| raise RecordInvalidError.new(foo.errors)
>> unless foo.errors.empty? }
>>
>> if foo.save || raise(PersistenceError.new(foo))
>> ...
>>
>> -Sam
>
> In the off chance that PersistenceError is raised, it's nearly
> useless, since it provides absolutely zero data about what went
> wrong. I also don't want that ugliness littering my code.
>
> This also seems like a rather unfortunate bunch of hoops to jump
> through when the ORM could just do it.
PMFJI. I've been following this thread and have to agree with Sam.
When you call a method like save, you have the opportunity to examine
the results of the operation using a return code and handle any errors
locally. Exceptions, because they are often not handled locally, can
lack proper context for the cause of the problem. Exceptions are for
exceptional conditions, not predictable ones. Do you expect your C
runtime library to raise an exception when an fwrite fails? No, it
returns an error code and you handle it because, as a programmer, you
know that conditions like disk full or permission denied can happen.
Same in Ruby. Check return values. Punting this off to the ORM is,
IMO, an inferior option as compared to testing the success of a
critical operation.
Just my (unasked-for) $.02
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
