[Webkit-unassigned] [Bug 139173] DOMError should be constructible as per the DOM4 specification

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=139173

--- Comment #25 from Chris Dumez <cdumez at apple.com> ---
(In reply to comment #24)
> (In reply to comment #23)
> > (In reply to comment #22)
> > > (In reply to comment #21)
> > > > Dear  All,
> > > > 
> > > >       DOMError can be removed from Webkit, since File APIs are not using it,
> > > > though as per FileReader Spec:http://dev.w3.org/2006/webapi/FileAPI/, the
> > > > error attribute still uses the DOMError. Also in MDN link DOMError is still
> > > > used in File APIs:
> > > > https://developer.mozilla.org/en-US/docs/Web/API/FileReader.error
> > > > 
> > > > Thanks
> > > 
> > > We still use DOMError in WebKit (for e.g. MediaStream and IndexedDB API,
> > > CSSFontFaceLoadEvent). It is likely that the corresponding specifications
> > > are not using DOMError anymore so our implementations would have to be
> > > updated first.
> > 
> > 
> > Dear  Chris,
> > 
> >       Yes right, we need to update our implementations for other module to
> > support using DOMError, may be later we can accept these changes, is it
> > right?
> 
> DOMError is still used in the W3C recommendation for IndexedDB
> (http://www.w3.org/TR/IndexedDB/)
> 
> The W3C recommendation for DOM4 (http://www.w3.org/TR/dom/) still includes
> DOMError in an appendix. It warns to not use it, and instead refer to
> "Error" in WebIDL (http://www.w3.org/TR/WebIDL-1/)
> 
> The previous working draft for DOM4
> (http://www.w3.org/TR/2015/PR-dom-20151006/) explains the real impetus
> behind that change - DOMError can't be removed because some specs still use
> it (Namely IndexedDB).
> 
> WebIDL defines "Error" as the set of all objects that can be used to
> represent an error, which correspond to the ECMAScript error objects
> (http://people.mozilla.org/~jorendorff/es6-draft.html#sec-error-objects)
> 
> ECMAScript error objects have a message property.
> 
> I have a few points for listing the current state of the specs WRT DOMError:
> 1 - DOMError is baked into the final IndexedDB spec, and therefore we can't
> remove it.
> 2 - But DOMError is strongly deprecated.
> 3 - DOMError's non-deprecated replacement is basically "an object
> representing an Error that has a message property"
> 4 - IndexedDB code sure would love to have custom messages in its DOMErrors
> instead of just a generic error code.
> 
> My personal takeaway from all of the above is that we *should* add the the
> message property to DOMError so it can better fulfill its purpose, but we
> should NOT add the constructor.
> 
> I still think the message part of this patch is relevant, and I would love
> to see it land soon.

Sure, I don't have any issue with adding the message attribute to DOMError. My main concern was about starting to expose DOMError on the global object, considering it is legacy.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151209/23a340b5/attachment.html>