I think it would be a good idea if it was possible to define custom exceptions that validation methods throw, instead of always throwing ActiveRecord::RecordInvalid. The syntax could be something like this: validates_presence_of :name, :exception => SomeException It would allow for much more elegant code, in cases where it is necessary to identify which validation failed. What do you think? I wouldn''t mind trying to implement this (in fact I''m very eager to do so!) although I''d need some guidance. Regards, André Silva -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Interesting idea. I''d suggest making sure that the exception classes are subclasses of ActiveRecord::RecordInvalid, so that rescue clauses can either care about the specific validation or not. -- Josh Susser http://blog.hasmanythrough.com On Mon, Aug 22, 2011 at 7:10 AM, André Silva <andre.beat@gmail.com> wrote:> I think it would be a good idea if it was possible to define custom > exceptions that validation methods throw, instead of always throwing > ActiveRecord::RecordInvalid. > > The syntax could be something like this: > > validates_presence_of :name, :exception => SomeException > > It would allow for much more elegant code, in cases where it is > necessary to identify which validation failed. What do you think? > > I wouldn''t mind trying to implement this (in fact I''m very eager to do > so!) although I''d need some guidance. > > Regards, > André Silva > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Which exception would you raise if 2 validations fail ? Robert Pankowecki -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Great question although I have no set answer :-( Maybe I should raise an exception for the "first" validation that fails? On Aug 22, 7:55 pm, Robert Pankowecki <robert.pankowe...@gmail.com> wrote:> Which exception would you raise if 2 validations fail ? > > Robert Pankowecki-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I feel that the conventional use case of validations is returning the object with the errors attribute(s) set to let you know which parts failed. A validation is used to confirm that user data entry conforms to necessary constraints, in normal processing (ie. a controller calling record.save) the exceptions are not raised and you need to deal with failure. If the code is being run in a programmatic way, that is the data entry is not coming from a user, and you are using record.save! it, in my read of the Rails conventions, be considered a programmatic error if it resulted in an exception. Your calling code should be giving valid values and not relying on exceptions to determine next action. The exception raised here should probably halt execution, or at the least send out crazy warnings (including examination of the record.errors object). Your use case may vary :) On Aug 22, 10:10 am, André Silva <andre.b...@gmail.com> wrote:> I think it would be a good idea if it was possible to define custom > exceptions that validation methods throw, instead of always throwing > ActiveRecord::RecordInvalid. > > The syntax could be something like this: > > validates_presence_of :name, :exception => SomeException > > It would allow for much more elegant code, in cases where it is > necessary to identify which validation failed. What do you think? > > I wouldn''t mind trying to implement this (in fact I''m very eager to do > so!) although I''d need some guidance. > > Regards, > André Silva-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
You are correct that my code is being run in a programmatic way, the data entry is not coming from a user but is instead coming from another system. Validations are a very powerful (and easy) way to make sure that the data that comes from the foreign system is correct. Still, I have to act upon invalid data in a programmatic way, i.e. I have to reply to the foreign system (and not just by giving it the errors hash). I could make sure that only valid values are given, but I would have to validate it on another layer, without relying on the powerful validation system provided by ActiveRecord. I know my use case is different than 99% of the typical usage scenarios. Still, I think this addition would improve the extensibility of validations. Regards, André Silva On Aug 23, 4:20 pm, Simon de Boer <sdeb...@ingamer.com> wrote:> I feel that the conventional use case of validations is returning the > object with the errors attribute(s) set to let you know which parts > failed. A validation is used to confirm that user data entry conforms > to necessary constraints, in normal processing (ie. a controller > calling record.save) the exceptions are not raised and you need to > deal with failure. > > If the code is being run in a programmatic way, that is the data entry > is not coming from a user, and you are using record.save! it, in my > read of the Rails conventions, be considered a programmatic error if > it resulted in an exception. Your calling code should be giving valid > values and not relying on exceptions to determine next action. The > exception raised here should probably halt execution, or at the least > send out crazy warnings (including examination of the record.errors > object). > > Your use case may vary :) > > On Aug 22, 10:10 am, André Silva <andre.b...@gmail.com> wrote: > > > > > > > > > I think it would be a good idea if it was possible to define custom > > exceptions that validation methods throw, instead of always throwing > > ActiveRecord::RecordInvalid. > > > The syntax could be something like this: > > > validates_presence_of :name, :exception => SomeException > > > It would allow for much more elegant code, in cases where it is > > necessary to identify which validation failed. What do you think? > > > I wouldn''t mind trying to implement this (in fact I''m very eager to do > > so!) although I''d need some guidance. > > > Regards, > > André Silva-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.