File API error inconsistency

[Drew Walters <de...@gmail.com>]

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.

Re: File API error inconsistency

[Filip Maj <fi...@adobe.com>]

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" <si...@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 <de...@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.
>>

Re: File API error inconsistency

[Simon MacDonald <si...@gmail.com>]

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