This is a pretty heated debate. I've read through this and related material. The question of whether or not to use exceptions is a bit beside my goals. My gut says exceptions are a part to a coherent solution and should not be sidelined for MRI implementation issues or religious reasons. But I want to find a total solution first with various examples of how to write clear app logic with or without exceptions.. This requires playing with more pieces of the puzzle and studying the forest, not the trees.
The arguments against exceptions for flow control are compelling but still leave me with app code that I find difficult to read. Take a look at this for an example of doing something very simply without exceptions: http://gist.github.com/31904 This is what should be a very simple controller action of activating a new user account. The view only has 4 fields, two of which are non- persistent. I can push some/most of this logic in the User model and its attribute definitions, but to be honest, that simply makes my code more complex to jump around to various pieces of code to find the entire flow of logic for a single use case. My only real religion is from pure OO design and I had to drop that religion due to a dwindling number of followers. Using ruby and its frameworks has been a problem for me at times because not everyone adheres to the basics: encapsulation (first and foremost), followed by key OO features of the language like inheritance and well defined interfaces which allow for the path of least surprise when it comes to polymorphism. If you use other "lesser" features, e.g. ruby's ability to modify anything from anywhere (which too many feel is a healthy form of metaprogramming), it should be done with strict regard to not interfering with the core principles of encapsulation and inheritance. Unfortunately the ruby world doesn't always play by this set of rules and I have to live with it or leave and go to a community which is more pure. Further, I suspect that when it comes to OOP, no such pure community exists anymore (or at least not one with ready to roll web libraries that don't bind me into using continuations for every request; yeah, seaside, I'm looking at you ;). I realize the above ramble seems off topic. I will try to steer this debate into something healthy and start a new thread. I accept ruby with its warts and the various ways rubyists (coming from different backgrounds) use it. However, I chose ruby and its related frameworks and libraries because I have a job to do: write rock solid web apps. I'm not developing toy apps where I can publish without worrying that my app may be hackable. I need peace of mind that my exposed controller actions are rock solid in that "they will not allow bad input and will not leak sensitive information as output." With that statement, I will start a new thread to discuss this need (I'll move it to the merb group). I will dive into DM issues as the Model and an ORM effect the bigger picture. My concerns are making wide assumptions that I want to use merb+dm in the same way rails has trained the world to munge MVC into something that I find disturbing. I greatly appreciate a healthy debate and hopefully we will find a path to DRY benefits without sacrificing good "MVC and OO design". thanks, Jon On Dec 3, 5:43 am, 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 -~----------~----~----~----~------~----~------~--~---
