4 ms·
the second example misses what is most important about Rails validations which is spitting errors (plural is important) out for a form. by using an exception wh
by benmmurphy 11y ago
the second example misses what is most important about Rails validations which is spitting errors (plural is important) out for a form. by using an exception which goes off when a field assignment is not valid it is restricted to only giving back a single error.
- jeremiep 11y agoTo me the article was more about the anti-pattern of having self-validating objects than trying to show where it can end badly. I now use only plain data (scalars, sequences and mappings) to represent data. The validation can be implemented independently and I can reuse all of the language's data manipulation functions. Its really the best of both worlds. As Rich Hickey said in "Simple Made Easy", the only thing you can do with data is destroy it by encapsulating it.
- solnic 11y agodry-validation supports typical validation behavior known from rails where errors are gathered and represented in a string representation. In fact it's much "smarter" than AR validations as it only executes validation functions that are needed and fill in other potential error messages based on rule definitions. This is one of the reasons why it's multiple times faster than AR validations and more extendible. With dry-data constrained types it's a different story. It raises type errors because we're dealing with lower level objects of your system. Personally I prefer to see a meaningful type error rather than exceptions like "foo called on nil" etc. Not to mention that constrained types increases the chance of spotting type-related bugs earlier.
- emergentcypher 11y agoWhy not throw an exception containing a list of invalid field errors instead of just one? That would only work in the constructor though not if you're setting fields individually.