An interesting option - I assume you mean returning a symbol. That would unfortunately break any existing code and you would have to do "if user.save == :success". It also would not succeed in bubbling up error type that aren't handled.
That is also again going back to C style return codes. Exceptions are a language function designed for doing this, and they are used throughout the Merb stack for similar situations. I don't see why they would be too heavy for validation errors in models. Exceptions in this case would have minimal impact and would make the code cleaner and more correct. I haven't looked much into ruby exception benchmarks. It would be unfortunate if people resort to not actually using ruby as it was designed because of such a performance issue. Perhaps someone can refer me to an article representing the general "anti-exception" argument Sam seems to subscribe to. On Nov 27, 11:19 pm, "Adam French" <[EMAIL PROTECTED]> wrote: > Has anyone considered throwing a symbol as opposed to raising an > exception when a save fails? Exceptions are heavy beasts in ruby and > perhaps using the throw-catch mechanism would be much more > lightweight. > > (proposed as an option for consideration) > === > Adam French > afrench on irc > > On Wed, Nov 26, 2008 at 11:48 PM, Alex Neth <[EMAIL PROTECTED]> wrote: > > > I don't know what other issue and that's the point. If a > > RecordInvalid exception is thrown, I know that there is a validation > > error and that I want to check user.errors and probably display the > > form again. I don't want to assume that is the case just because the > > save failed. > > > That is unless the contract of the save method says "returns false > > means there was a validation error and user.errors contains the > > details." Right now the contract just says that false means the save > > failed. The point is I don't want to have to think "is there some > > other cause of returning false?" > > > I gave the example of a PermissionsError, if permissions were > > integrated into the model. In that case it would still return false > > (following the current pattern) and I would have to check user.valid? > > and then check user.can_save? or something. Even calling user.valid? > > is not 100% accurate here, since validation will be rerun and perhaps > > the state has changed from passage of time, insertion of new records, > > etc. I want the validation error bubbled up when it happens. > > Anything else is not accurate. > > > On Nov 26, 8:27 pm, Jon Hancock <[EMAIL PROTECTED]> wrote: > >> I think he means that RecordInvalid is _one_ of the exceptions that > >> might be raised. Another for the case of a save could be > >> DuplicateRecord. > > >> Jon > > >> On Nov 26, 7:51 pm, Michael Klishin <[EMAIL PROTECTED]> > >> wrote: > > >> > On 26.11.2008, at 12:25, Alex Neth wrote: > > >> > > Right now I can stop execution with an "if user.save," but I need to > >> > > probe the object for the reason - is it invalid? is there some other > >> > > issue? > > >> > What other issues can it be? If RecordInvalid-like exceptions would be > >> > raised, don't you face the same problem? > > >> > MK > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
