Just to relay here what I discussed with Allen in the off-periods of the last TC39 meeting.
On Wed, Jul 17, 2013 at 12:30 AM, Jonas Sicking <[email protected]> wrote: > x.name == "HierarchyRequestError" > This should test true. This should be uncontroversial enough that I > don't think it matters how much dependency there is, right? Obviously > the exact value varies with the exception type. Given that for every JavaScript exception x.name is the name of the object, violating that is actually breaking a pattern. x.name should be DOMException. We could have x.subname that would be something more specific. > I think we have the following constraints for properties that contain > error information in APIs that currently use DOMError > (IDBTransaction.error in the IndexedDB spec for example). > > x.name = "AbortError" > This should be uncontroversial enough that I don't think it matters > how much dependency there is, right? This has the same problem. It might be worse here. > My recommendation would be to > * Get rid of DOMError and use DOMException in its place Agreed. > * Add new subclasses for each exception type. I.e. exceptions with > .name == HierarchyRequestError should also test true for "instanceof > HierarchyRequestError" Allen and I both agreed this would be overkill. Using .subname or some such should be sufficient. > * Keep specifying that DOMException is a subclass of Error. This is > already the case, but I wanted to make it clear that this shouldn't > change. Agreed. -- http://annevankesteren.nl/ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
