Native can either: 1. Return an object that, for all purposes, looks and has the same structure as the FileError object straight to JS. 2. Return only the primitive data type(s) that we can easily build up a FileError object in JS for.
My problems with (1): - if you do an `instanceof` call on the object to, say, check if it is an instance of the FileError object, it will return false, unless we include the use of the FileError constructor / module in the native side. However, then we're moving *more* JS into the native side. We don't want to do that. - what's being passed to/from native is larger, but that is much less of an issue. - we're maintaining more JavaScript in both the JS layer as well as the native side. By using (2) and constructing things like error objects in the WebView on the JS side we are also making it easier to maintain as we have a single spot in the code that does this. Hopefully as we move forward, this will be all done in the cordova-js code and, ideally, done once across platforms as well. On 12-02-24 7:42 AM, "Simon MacDonald" <simon.macdon...@gmail.com> wrote: >Yeah, I saw that change too. I was wondering what the advantage of >returning an integer vs returning a FileError object? > >Simon Mac Donald >http://hi.im/simonmacdonald > > >On Fri, Feb 24, 2012 at 9:54 AM, Drew Walters <deedu...@gmail.com> wrote: > >> I've been working through the File API mobile-spec failures on >> BlackBerry and have encountered some inconsistency in how error codes >> in the JS are handled. Some of the JS API >> (DirectoryEntry.removeRecursively, DirectoryReader.readEntries, >> Entry,getMetadata, Entry.getParent, window.requestFileSystem) expect >> the native side to return a FileError object in the error result, >> while the rest expect the native side to just return an integer error >> code (which is used on JS side to create FileError object). >> >> Should the native code return a FileError object or just the integer >> error code? We need to choose one because it is too error >> prone/frustrating right now to try to get the native side to properly >> handle the error for each individual API. >>
