- From: Arun Ranganathan <arun@mozilla.com>
- Date: Fri, 15 Apr 2011 19:01:51 -0400
- 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 UTC