Nevermind then, guess it's in ...




On Thu, Nov 22, 2012 at 12:51 PM, Andrew Grieve <agri...@chromium.org> wrote:
> 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 <agri...@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 <pmue...@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
>>> >
>>>
>>
>>



-- 
@purplecabbage
risingj.com

Reply via email to