Re: WebApps-ISSUE-181 (FileError-Name): Use case for FileError and FileException name attribute [File API]

On Mon, Jun 6, 2011 at 4:28 PM, Web Applications Working Group Issue
Tracker <sysbot+tracker@w3.org> wrote:
> FileError [1] and FileException [2] both define a DOMString attribute called name that contains the name of the error/exception constant as a string. Since this is not a useful "human readable" error message, and developers should be encouraged to write code that compares against the code attribute, it's not clear what the purpose of 'name' is. We'd prefer to remove it.

This matches the specification for DOMException:

http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-domexception-name

For DOMException, every current browser except IE exposes the string
in some fashion.  Chrome 13 dev follows the DOM Core spec, Opera 11.11
has the same value under the message attribute, and Firefox 5.0a2 has
the value under the name attribute but prefixed with "NS_ERROR_".  In
IE9, the message attribute contains something like "DOM Exception:
HIERARCHY_REQUEST_ERR (3)", which is only marginally more
human-readable than just "HIERARCHY_REQUEST_ERR".

I'm not strongly attached to name, but we should have some
standardized string exposed as an attribute that contains the string
form of the error code, so authors who run into the exception will
have something to Google.  The numeric error code is only useful if
you know what code you're looking for in advance.  The string code is
useful so that you have something memorable to refer to it by, search
for, etc.  Also, if you're reading function documentation and it
describes what errors are thrown, it will normally use the string
code, not the numeric code, so if the object only contains the numeric
code it will be hard to figure out from the documentation which error
condition was hit.

Currently everyone exposes the string code somewhere or other on the
exception object, at least for DOMException (and FileException et al.
should match IMO).  The exact location and format just needs to be
standardized.  Maybe we could just standardize the message attribute,
since it seems like everyone puts *something* more or less
human-readable there?

Received on Monday, 6 June 2011 22:57:52 UTC