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 <[email protected]> wrote:
> On Wed, Jul 10, 2013 at 12:52 PM, Domenic Denicola
> <[email protected]> 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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss



-- 
erik
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to