Jonas, DOM never throws DOMError. DOMErrors are used for other error
mechanisms, such as callbacks. [1]

The DOM spec does however throw DOMException objects [2]. These are
instanceof Error (see WebIDL [3])

var ex;
try {
  document.appendChild(document);
} catch (e) {
  ex = e;
}
assert(ex instanceof Error);
assert(ex.contructor === DOMException);
assert(ex.name === 'HierarchyRequestError');

In Blink DOMException also have a stack property
assert(stack in ex);

[1] http://dom.spec.whatwg.org/#interface-domerror
[2] http://dom.spec.whatwg.org/#exception-domexception
[3] http://dev.w3.org/2006/webapi/WebIDL/#es-exception-interface-prototype-object

On Wed, Jul 10, 2013 at 3:02 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Wed, Jul 10, 2013 at 12:52 PM, Domenic Denicola
> <domenic at domenicdenicola.com> wrote:
>> Woah, François, that seems pretty overcomplicated; why not replace everything inside the constructor with `this.message = message`? It has the same effect in the browsers I've seen. (Also don't forget `SomeError.prototype.constructor = SomeError`.)
>>
>> Anyway, to Jonas's point: I think `DOMError` is actually pretty OK. One thing I noticed is that the ES5 spec (and presumably ES6, although I haven't checked) is careful to never throw simple `Error` objects, but instead `TypeError`s or `RangeError`s or so on. I infer that they are leaving bare `Error` for user cases. I think "the platform" should generally follow this lead; that is, the DOM should leave bare `Error`s to the user, and throw `DOMError`s or `TypeError`s or `RangeError`s for its own errors.
>>
>> To answer your more general question, authors are strongly discouraged from ever throwing anything that is not `instanceof Error`, see e.g. Guillermo Rauch's [A String is not an Error](http://www.devthought.com/2011/12/22/a-string-is-not-an-error/). Also, the `name` property is generally the same across all instances of a particular error type, i.e.
>>
>> ```js
>> errInstance.name === errInstance.constructor.name === errInstance.constructor.prototype.name === Object.getPrototypeOf(errInstance).name
>> ```
>>
>> (You can verify this for all the built-in ES5 errors.) Usually a `code` property is used for more specific information, from what I've seen. But yes, that has to be added manually with a bit of awkwardness, i.e.
>>
>> ```js
>> const e = new DOMError("The message");
>> e.code = "TimeoutError";
>> throw e;
>> ```
>
> Note that
>
> (new DOMError) instanceof Error;
>
> returns false. So the DOM does do the "strongly discouraged" thing. Is
> this ok or bad?
>
> Also, the DOM does not create a new class for each different value of .name.
>
> I.e. you can get a DOMError whose .name is "NetworkError" or
> "AbortError". DOMError even has a constructor which allows setting
> .name to anything: new DOMError(name, message);
>
> In fact, there are no defined situations where the DOM creates
> DOMError objects whose .name is "DOMError".
>
> Again, is this ok or is it bad practice?
>
> / Jonas
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



-- 
erik

Jonas, DOM never throws DOMError. DOMErrors are used for other error
mechanisms, [such as callbacks](http://dom.spec.whatwg.org/#interface-domerror).

The DOM spec does however throw [DOMException objects](http://dom.spec.whatwg.org/#exception-domexception). These are instanceof Error (see [WebIDL](http://dev.w3.org/2006/webapi/WebIDL/#es))

```js
var ex;
try {
  document.appendChild(document);
} catch (e) {
  ex = e;
}
assert(ex instanceof Error);
assert(ex.contructor === DOMException);
assert(ex.name === 'HierarchyRequestError');
```

In Blink DOMException also have a stack property

```js
assert(stack in ex);
```