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 On Dec 2, 3:53 am, Alex Neth <[EMAIL PROTECTED]> wrote: > > I think we need to agree to disagree on this one. I'm not as up to > > speed on Ruby's exception structure as C-like languages, but it stands > > to reason that there would be similarities. Every time an exception > > context is established, a set of unwindable frames need to be created > > so your program can basically perform a non-local jump outside its > > current execution context while at the same time cleaning up objects > > left lying around unfinished all the way up the call stack until the > > exception is finally handled. Garbage collection simplifies this > > immensely, but doesn't make the overhead go away completely. You are, > > therefore, suggesting an implementation decision at the ORM level that > > is more memory-intensive and cpu-intensive strategy than simply > > returning values. > > > In many ways, merb *is* a good model because they have tried to make > > implementation decisions (down to what ORM if any should be used) that > > could sensibly be decoupled from the framework easy to decouple. That > > might be a good way to look at error propagation strategies. I think > > DataMapper is currently at a point where it is not tied to Ruby's > > exception handling. If that's part of your implementation strategy, > > wrappingsave! (as was previously suggested) is one option. You could > > also fork the project and implementsavein your preferred style. > > You'd probably get most of the goodness of the project in merges. And, > > you might be right.Exceptionsmight be superior in all ways to simple > > error returns. That's what's great about Open Source: You can have it > > your way and if your was is a better one, people will recognize that. > > As far as the mechanism ofexceptionsbeing expensive, I'm not sure > that's inherently so, although that implementation level of the > language is not an area I'm an expert in. > > There is no reason for it to actually assemble a string backtrace > though until backtrace is called. It seems would only need to store > some sort of stack reference. I'm not speaking from a compiler > background though. > > I am quite convinced that in this case of DM,exceptionsare > superior. I'm not sure at this point it justifies me maintaining a > fork. I was hoping to get my position out there. Perhaps it will come > up again. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
