> 1.) Java ORMs make use of exceptions all the time and no one would > accuse Java of being slow.
ROFLCOPTER. I think you guys are beating a dead horse. If you want to know why your save failed, it'll be in #errors, if its not it sounds like you didn't write well enough validations. > 2.) I thought the goal of an ORM was to optimize for developer time > and to help them stay DRY. This methodology makes it absolutely dry. if @user.save @user.login else # and my form handles telling the user what they did wrong, which users ALWAYS do stuff wrong, thus this isn't an exception, its a normality. return @user end On Dec 2, 1:43 pm, Vivek Sharma <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
