- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Fri, 15 Apr 2011 18:29:22 -0400
- 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: 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?
Received on Friday, 15 April 2011 22:30:12 UTC