I just checked in argscheck.js and refactored all applicable lower-case plugin/*.js files to use it.
It trims 4k off of cordova.ios.js and git tells me: 245 insertions(+), 323 deletions(-) I also found that a couple of our tests were passing invalid arg types :P On Thu, Nov 22, 2012 at 3:48 PM, Andrew Grieve <[email protected]> wrote: > There's a good amount of code that currently check types on the public > API. My goal here is to shrink that code because it seems repetitive. > > Checking the types passed to exec may be useful in some cases too, but we > don't currently do that. Probably, if we wanted to add this in, we'd want > something more sophisticated that actually checked JSON schemas instead of > just checking for typeof 'object'. > > > > > On Thu, Nov 22, 2012 at 1:19 PM, Brian LeRoux <[email protected]> wrote: > >> Ok, hold up, I'm missing something---I thought this was for the *bridge >> protocol validation* not the actual API surface end developers invoke. >> >> Ideally the public API would define their own exceptional paths. (Har >> har.) >> Example: geolocation api has error callbacks whereas File API has >> FileError >> (or some such / on bad connection and just blasting this w/o checking). >> >> >> On Thu, Nov 22, 2012 at 2:01 PM, Patrick Mueller <[email protected]> >> wrote: >> >> > On Thu, Nov 22, 2012 at 6:00 AM, Brian LeRoux <[email protected]> wrote: >> > >> > > ya upon further consideration making these TypeException's feels right >> > > since, ideally, this error would only be seen by a plugin author and >> not >> > > something a plugin consumer (ideally) >> > > >> > >> > huh? I thought this was all about informing users when they pass >> invalid >> > arguments? >> > >> > I'm usually in favor of "fail fast" - and so throwing an exception when >> you >> > pass an invalid argument sounds right to me. The problem is that even >> > though it's simple for us to fail fast by throwing an exception, we also >> > need to make sure it's super obvious to the user that a failure has >> > occurred. That's the hard part. Too many places where errors are >> silently >> > consumed by the runtime. >> > >> > I think a console.log() would be appropriate - along with a thrown >> > exception - lots of folks have access to a "console" these days. Or >> maybe >> > we should come up with a new API - reportFailure() or something, which >> we >> > could have - by default - just log to the console. For platforms that >> > don't have an easily accessible console, they can override this to do >> > something visible for their platform. >> > >> > -- >> > Patrick Mueller >> > http://muellerware.org >> > >> > >
