Erik Arvidsson (2013-07-17T00:05:28.000Z)
On Tue, Jul 16, 2013 at 4:30 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> Object.toString(x)

I assume you mean Object.prototype.toString.call(x)

> I *don't* think it's important what this returns. I.e. I would guess
> that we can safely subclass DOMException as needed.
>
>
> 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 instanceof DOMError
> Probably doesn't matter what this returns.

FWIW, Neither Blink nor WebKit exposes DOMError so this should be safe
to change (on the open web at least).

> x.name = "AbortError"
> This should be uncontroversial enough that I don't think it matters
> how much dependency there is, right?
>
> x.message
> This probably needs to contain a human readable error message. This
> should be uncontroversial enough that I don't think it matters how
> much dependency there is, right?
>
> Object.toString(x)
> Probably doesn't matter what this returns.
>
>
> I doubt that in either case it matters if these properties live on the
> objects themselves, or on the prototype chain.
>
>
> So all in all, I think we have a lot of room for what to do in both
> cases. The only requirements is that exceptions *likely* need to test
> true for "instanceof DOMException", and that they in some cases need
> to have a specific numeric code property.
>
> My recommendation would be to
> * Get rid of DOMError and use DOMException in its place
> * Add new subclasses for each exception type. I.e. exceptions with
> .name == HierarchyRequestError should also test true for "instanceof
> HierarchyRequestError"
> * 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.
>
> I personally think that the second bullet is a bit silly. But since
> that appears to be the convention that ES uses then we should stick
> with it.

Agreed.

There will be issues here since DOM has throw a SyntaxError, which
means throw a DOMException with the name SyntaxError and the code
DOMException.SYNTAX_ERR so that would mean that we have a naming
conflict since ES already have a SyntaxError constructor.


--
erik
domenic at domenicdenicola.com (2013-07-19T15:57:18.067Z)
On Tue, Jul 16, 2013 at 4:30 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> ```js
> Object.toString(x)
> ```

I assume you mean `Object.prototype.toString.call(x)`

> ```js
> x instanceof DOMError
> ```
> Probably doesn't matter what this returns.

FWIW, Neither Blink nor WebKit exposes `DOMError` so this should be safe
to change (on the open web at least).

> I personally think that the second bullet is a bit silly. But since
> that appears to be the convention that ES uses then we should stick
> with it.

Agreed.

There will be issues here since DOM has throw a `SyntaxError`, which
means throw a `DOMException` with the name `SyntaxError` and the code
`DOMException.SYNTAX_ERR` so that would mean that we have a naming
conflict since ES already have a `SyntaxError` constructor.