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; ``` _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
