Sam, When you say "exceptions should not be used for flow-control", it sounds so right that I have to say I'm part of that religion as well.
However, a few years back I had a "religious experience" whereby I decided that anything not "correct" was an exception and should trigger an "abend" of sorts. About 4 years ago, I wrote an app in erlang. During the dev process, I had non-IT end users playing with a live dev system. Yikes!!! Normally, you would expect this to be a huge mess. After a few months of this, I recognized that although the end users were experiencing all sorts of errors, I never had a single instance of data corruption in my DB. None. The server never even crashed once. I was blown away by this experience and it changed me forever ... swim to the light ;) It was after this experience that I read Joe Armstrong's PhD thesis http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf. A major assertion is his principle "let it fail". erlang is beautiful in this regard. You code for concrete correct behavior and everything else fails, fast and hard. In this regards, a user that mistypes an email address while activating an account (whether its an email format error or the email address is not in the DB) ends up failing quickly at the point where I look up the address. I do not have to put any conditional logic to see if the DB read returned a User object. If all does not go according to plan, the process fails. My code ended up being very clean. It read like prose (in erlang syntax, so some wouldn't consider it prose) in that only the correct behavior was in my app code. Any errors were handled by the "framework" (in this case Erlang/OTP and a sprinkling of my own magic) and the only job left in the aftermath was to write user friendly error messages for the exceptional cases. Since I had this experience, I find myself trying to graft it on top of other web app endeavors. My instinct tells me that if I can approximate this in ruby, that it will happen through careful refactoring of code with heavy use of exceptions. I can't prove this is the right route to nirvana, but I'm going to keep trying. So I guess I'll add my own "!" methods and see where it leads. thanks again Sam for such a nice ORM!!! Jon On Oct 30, 2:34 am, Sam Smoot <[EMAIL PROTECTED]> wrote: > That was my decision. It's a religious thing I don't expect everyone > to agree with. I'm firmly in the "exceptions should not be used for > flow-control" camp. ;-) > > The exception being that a get for a specific id should always raise > because it's an exceptional situation not to find the object then. So > that's the direction things are going in. No bang variations. > > That said, I have no issue at all with a plugin to add those > methods... > > -Sam > > On Oct 29, 12:46 pm, Jon Hancock <[EMAIL PROTECTED]> wrote: > > > Let me start by saying that I like exception oriented code. > > That said, most times I would want to use get! instead of get. > > > It follows that I would want to use find! and first! as well. But > > these do not exist. > > I heard a month or so ago that the ! style methods may go away. > > > Can one of the dm devs explain the intentions? > > > I would really love to see dm have a full set of exception-oriented > > finder functions. > > > One such function I would like is a "find_one" finder. This would be > > a method like one!, or a param to an existing finder, whereby it would > > throw an exception if the result returned anything other than one and > > only one result. > > > just my 2 cents. > > thanks, Jon --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
