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

Re: HTML5 Filesystem API feedback

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Fri, 15 Apr 2011 18:29:22 -0400
Message-ID: <BANLkTikZ_jr9Dg8R7UiKJ6XOGWBehq0ntA@mail.gmail.com>
To: Robert Ginda <rginda@chromium.org>
Cc: public-webapps@w3c.org
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:


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?
Received on Friday, 15 April 2011 22:30:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:19 UTC