Igal wrote: > If a method returns an unexpected object, and we haven't taught all the > rest of our code to check whether it received an imposter, it's too easy to > accidentally have our code treat it like a real object.
I thought that was the whole point of duck typing; that you shouldn't obsess over the "real object"/"impostor" distinction. If Nick is correct that this blank report doesn't pass validation, where exactly does the problem arise? Would having the rescue return nil (and adding a "report_is_present" validation) suffice? This assumes on the validations being ordered, which I'm not enough of a rails nerd to know the practicality of. Nick wrote: > [one] alternative is to make all of our code smart enough to > handle the (supposedly impossible) case where an invalid report does make it > into the system. I would rather not add lots of special handling for > something which is theoretically not possible. I wholeheartedly agree. Especially since the list of things that are theoretically impossible is...rather large. You can't have a policy of checking for them, or your code will grow without bound. Nick wrote: > It might be possible to catch the error when it happens and transform it > into a validation failure. I will investigate that. That would be a lot better. The patch as written appears to depend on the report_contains_metrics validation knowing that what it got was "wrong." -- Markus ----------------------------------------------------------- The power of accurate observation is commonly called cynicism by those who have not got it. ~George Bernard Shaw ------------------------------------------------------------ -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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/puppet-dev?hl=en.
