cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse MacFadyen <purplecabb...@gmail.com>
Subject Re: Type checking in Cordova JS plugins
Date Thu, 22 Nov 2012 16:40:27 GMT
In the original thread the rational was that things were inconsistent,
but the examples were disparate.

notification.alert(108);
// This is valid and should not fail, and a callback function (win or
lose) is not required.

resolveLocalFileSystemURI.js
// actually, it checks that there are not multiple colons, I wrote
this to resolve a specific issue and fixed it in js to patch all
platforms at once

Backing up to the original questions ;

1. Should we check types or not?
- sometimes yes, sometimes no, depends on the case, but this is
difficult to achieve generically as a framework and should be left to
the plugin developer.
2. Success / error callbacks : optional or not?
- optional! Sometimes callback need to be optional, like console.log
3. When type errors happen, log & return, call errBack, or throw TypeError?
- I think we should always log errors, and provide as much info as
possible, however this can only really be done by leading by example.
- generally, I think we should be calling the provided error callback
if available, so that developers do not have to use both try/catch +
callback.

Andrew, your type checking code is certainly interesting, however I
don't think it belongs in the cordova-js framework. Maybe this should
be a standalone tool, in it's own repo ... are you still pushing to
add this?

Cheers,
Jesse

Sent from my iPhone, forgive fat fingers.


On 2012-11-22, at 6:55 AM, Andrew Grieve <agrieve@chromium.org> wrote:

> Good point Patrick. I'll go with a console.log + exception.
>
>
> On Thu, Nov 22, 2012 at 9:01 AM, 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
View raw message