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 <agri...@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 <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 >>