cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Type checking in Cordova JS plugins
Date Thu, 22 Nov 2012 20:51:41 GMT
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 <agrieve@chromium.org> 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 <b@brian.io> 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 <pmuellr@gmail.com>
>> wrote:
>>
>> > On Thu, Nov 22, 2012 at 6:00 AM, Brian LeRoux <b@brian.io> 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
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message