On Thu, Nov 22, 2012 at 11:40 AM, Jesse MacFadyen <purplecabb...@gmail.com>wrote:
> 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. > The idea here is that type errors should not happen, so there's no need for devs to add try/catches. e.g., you don't add a try/catch around calls to browser APIs that guard against you passing in the wrong parameter types. I think of this more like an assertion. The example of the colons is one that my refactoring will not address. I'm going to stick strictly to checking types so that there won't be much code. > > 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? > Yes. Still would like to add this. My motivation here is not to add something new, but rather to delete lines of code within our core plugins. I don't think it makes sense to have it in a separate repo, or else we'll have cordova-js depending on this other repo. > > 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 > >> >
