Folks, I think I'm going to have to side with Alex on this one. Let's clearly state the problem:
"Sending a return code back rather than an exception causes a certain amount of opaqueness in the code. It's becomes impossible to know the real details of an error." IMHO, I also think that adding all of these validation checks around the error is very un-DRY. It makes a lot of sense for me to have the ORM handle this. I think the argument against exceptions finally comes down to this: "We will take a huge performance hit for using validation exceptions. Therefore we won't do it." A couple comments: 1.) Java ORMs make use of exceptions all the time and no one would accuse Java of being slow. 2.) I thought the goal of an ORM was to optimize for developer time and to help them stay DRY. It seems to me that if there really are huge performance issues with Ruby's exception handling then that's where the energy should be dedicated and it should be fixable (as shown by Java). -- Vivek --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
