W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: HTML5 Filesystem API feedback

From: Arun Ranganathan <arun@mozilla.com>
Date: Fri, 15 Apr 2011 19:01:51 -0400
Message-ID: <4DA8CE5F.3000208@mozilla.com>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
CC: Robert Ginda <rginda@chromium.org>, public-webapps@w3c.org
On 4/15/11 6:29 PM, Aryeh Gregor wrote:
> On Wed, Apr 13, 2011 at 4:35 PM, Robert Ginda<rginda@chromium.org>  wrote:
>> * The FileError object is a bit awkward to work with.  I found that I
>> frequently had every reason to expect my calls to succeed (because
>> they were a follow-on to something that already succeeded), but I
>> wanted to log the failure reason in the event they didn't.  The code
>> online suggests a switch/case statement to turn error codes into
>> mnemonic strings.  This requires a hardcoded list of all known errors,
>> and a call out to this utility function every time you want to display
>> the error reason in a readable way.  I suggest adding the mnemonic
>> string as a property of FileError, and displaying it as part of the
>> toString.  (See util.getFileErrorMnemonic() and
>> util.installFileErrorToString() for example implementations.)
> I'd suggest solving this the same way as DOMException does, for consistency:
>
> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#exception-domexception
>
> It has a "name" property that contains the name, e.g.,
> "INDEX_SIZE_ERR" or "INVALID_STATE_ERR".  Of course, if you want to
> display a real error message you have to localize it, but an
> easily-recognizable, memorable, Google-able string is still extremely
> useful in many cases.  Plus, DOMException already does it and it's
> about two lines to spec, so why not?
>

This sounds like a reasonable addition to both FileException and 
FileError; I'll make this change in File API.

-- A*
Received on Friday, 15 April 2011 23:02:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:44 GMT